Individual Submission S. Das
Internet-Draft Independent Inventor
Intended status: Informational 22 October 2026
Expires: 25 April 2027
Protected Execution-Finality Enforcement for Autonomous AI Agents Across
Kernel, Hypervisor, Hardware, and Native-Resource Boundaries
draft-das-kernel-hardware-execution-finality-00
Abstract
This document describes a proposed execution-finality architecture
for autonomous agent workloads at kernel, hypervisor, device, and
native-resource effectuation boundaries. It distinguishes
computation from authority to commit consequential effects, and
documents protected validation, operation-bound evidence, scoped
authorization, independent finality verification, revocation, and
containment, alongside deployment profiles and illustrative
algorithms and tests.
Industry Relevance: Recent public developments in autonomous AI-agent
security and execution governance include Microsoft Execution
Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030
(Action-Bound, Fail-Closed Approval Protocol), and Project
Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel
AI-Agent Security Architecture; NVIDIA OpenShell Reference
Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK,
and Responses API; and Anthropic Claude Managed Agents, Claude Code
Sandboxing, and Claude Code Auto Mode. These initiatives illustrate
industry attention to agent isolation, independent policy
enforcement, action-bound authorization, delegated authority,
credential isolation, network-egress security, hardware-assisted
containment, runtime supervision, and fail-closed controls. This
draft describes related proposed execution-finality mechanisms
without asserting that these initiatives implement them.
Relevance to the IETF: the mechanisms described here require common,
interoperable objects and verification semantics across independently
built components, including operation descriptors, act-bound non-
bearer capabilities, finality-sink verification results, validation
evidence, and authority, revocation, and containment generations.
The document relates to existing IETF work on OAuth, GNAP, RATS,
WIMSE, and SCITT, and asks the community whether and where this
effectuation-boundary problem should be addressed.
Das Expires 25 April 2027 [Page 1]
Internet-Draft Kernel-Hardware Execution Finality October 2026
This document is intentionally long and is not repetitive: each
profile specifies a distinct mechanism with its own algorithms,
failure cases, and enforcement points, and the security properties
depend on how these mechanisms combine. A reduced excerpt would hide
the conditions under which they fail closed, so this document and its
two companion drafts, among which the profiles are divided, are meant
to be evaluated as a whole.
This draft builds on earlier Internet-Drafts by the same author, in
particular draft-das-agent-execution-finality, and adds mechanism
families not described there; the Introduction states precisely what
was disclosed earlier and what is disclosed here.
IPR: The technical content of this draft set is based upon the
author's international application PCT/IB2026/055615, which forms the
foundation of this disclosure and comprises approximately 300
distinct, non-repetitive embodiments and enforcement points. A
separate patent application specific to the material in this draft
set has also been filed. Related Indian applications: 202531130665,
202631000572, 202631001586, 202631002990, 202631124028, and
202631125689. Related international applications: PCT/IB2025/058316,
PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/
IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/
IB2026/056941. These identify related technical disclosures; not all
described mechanisms are necessarily patent-claimed or granted, and
patent scope and priority depend on applicable law and examination.
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 25 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Das Expires 25 April 2027 [Page 2]
Internet-Draft Kernel-Hardware Execution Finality October 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 35
1.1. This Document Is Intentionally Long . . . . . . . . . . . 36
1.2. Document Set and Cross-References . . . . . . . . . . . . 37
1.3. Profile Map . . . . . . . . . . . . . . . . . . . . . . . 38
1.4. Relationship to Earlier Internet-Drafts . . . . . . . . . 41
1.4.1. What the Earlier Drafts Disclosed . . . . . . . . . . 41
1.4.2. What This Draft Set Discloses . . . . . . . . . . . . 43
2. IPR and Related Patent Disclosures . . . . . . . . . . . . . 46
2.1. Related Indian Patent Disclosures and Claimed Priority . 46
2.2. Related International Patent Applications and WIPO
Publications . . . . . . . . . . . . . . . . . . . . . . 46
2.3. Scope and Priority Qualifications . . . . . . . . . . . . 47
3. Problem Statement and Security Objectives . . . . . . . . . . 47
3.1. General Problem . . . . . . . . . . . . . . . . . . . . . 47
3.2. Specific Problems . . . . . . . . . . . . . . . . . . . . 48
3.3. Primary Focus of This Draft . . . . . . . . . . . . . . . 52
3.4. Security Objectives . . . . . . . . . . . . . . . . . . . 53
4. Relevance to the IETF . . . . . . . . . . . . . . . . . . . . 53
4.1. Why This Is IETF Work . . . . . . . . . . . . . . . . . . 53
4.2. Relationship to Existing IETF Work . . . . . . . . . . . 54
4.3. What the Community Is Asked to Evaluate . . . . . . . . . 54
5. Industry Alignment and Technical Relevance . . . . . . . . . 55
6. Scope and Terminology . . . . . . . . . . . . . . . . . . . . 55
6.1. Technology-Neutral Architectural Definitions . . . . . . 56
6.2. General Interpretation . . . . . . . . . . . . . . . . . 61
6.3. Execution Environments and Sandbox Architectures . . . . 62
6.4. Operations, Effects, and Effectuation Boundaries . . . . 66
6.5. Protected Domains and Execution Authority . . . . . . . . 71
6.6. Algorithmic and Runtime Verification . . . . . . . . . . 76
7. Source-Derived Technical Implementation Profiles . . . . . . 78
7.1. Implementation Profile S-5 . . . . . . . . . . . . . . . 79
7.1.1. S-5.1 - Technical Field . . . . . . . . . . . . . . . 79
7.1.2. S-5.2 - Technical Problem . . . . . . . . . . . . . . 80
7.1.3. S-5.3 - Technical Objectives . . . . . . . . . . . . 81
7.1.4. PART I - PRINCIPAL SYSTEM ARCHITECTURE . . . . . . . 81
7.1.5. S-5.4 - Principal Components . . . . . . . . . . . . 81
7.1.6. Component A - Computing Platform . . . . . . . . . . 82
7.1.7. Component B - Operating-System Kernel . . . . . . . . 82
7.1.8. Component C - Optional Hypervisor . . . . . . . . . . 82
Das Expires 25 April 2027 [Page 3]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.9. Component D - Artificial-Intelligence-Agent Execution
Context . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.10. Component E - Kernel Enforcement Interface . . . . . 82
7.1.11. Component F - Hypervisor Enforcement Interface . . . 82
7.1.12. Component G - Execution-Context Attribution
Controller . . . . . . . . . . . . . . . . . . . . . 82
7.1.13. Component H - Candidate Act Interceptor . . . . . . . 83
7.1.14. Component I - Non-Effective Operation Holder . . . . 83
7.1.15. Component J - Protected Enforcement Domain . . . . . 83
7.1.16. Component K - Protected Validation Evidence
Controller . . . . . . . . . . . . . . . . . . . . . 83
7.1.17. Component L - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 83
7.1.18. Component M - Finality Sink . . . . . . . . . . . . . 83
7.1.19. Component N - Protected State Registry . . . . . . . 83
7.1.20. Component O - Effectuation-Path Coverage
Controller . . . . . . . . . . . . . . . . . . . . . 83
7.1.21. Component P - Operation Recovery Controller . . . . . 83
7.1.22. S-5.5 - Representative Kernel-Mediated
Architecture . . . . . . . . . . . . . . . . . . . . 84
7.1.23. PART II - KERNEL ENFORCEMENT . . . . . . . . . . . . 84
7.1.24. S-5.6 - Kernel Enforcement Boundary . . . . . . . . . 84
7.1.25. S-5.7 - System-Call Mediation . . . . . . . . . . . . 85
7.1.26. S-5.7.1 - System-call limitation . . . . . . . . . . 86
7.1.27. S-5.8 - Linux Security Module Implementation . . . . 86
7.1.28. S-5.8.1 - Protected-domain relationship . . . . . . . 86
7.1.29. S-5.8.2 - Authorization state . . . . . . . . . . . . 87
7.1.30. S-5.9 - eBPF Observation and Enforcement . . . . . . 87
7.1.31. S-5.9.1 - Observation is not enforcement . . . . . . 87
7.1.32. S-5.9.2 - Application semantic limitation . . . . . . 87
7.1.33. S-5.9.3 - Configuration integrity . . . . . . . . . . 88
7.1.34. S-5.10 - Kernel-Controlled Protected State . . . . . 88
7.1.35. PART III - HYPERVISOR ENFORCEMENT . . . . . . . . . . 89
7.1.36. S-5.11 - Hypervisor-Mediated Execution . . . . . . . 89
7.1.37. S-5.11.1 - Trust separation . . . . . . . . . . . . . 89
7.1.38. S-5.12 - Hypervisor Interception . . . . . . . . . . 89
7.1.39. S-5.12.1 - Actual effect boundary . . . . . . . . . . 90
7.1.40. S-5.13 - Second-Stage Memory Protection . . . . . . . 90
7.1.41. S-5.14 - Hypervisor-Controlled Device Backend . . . . 91
7.1.42. S-5.14.1 - Alternative backend . . . . . . . . . . . 91
7.1.43. PART IV - HARDWARE-ASSISTED PROTECTION . . . . . . . 91
7.1.44. S-5.15 - Hardware-Assisted PED . . . . . . . . . . . 91
7.1.45. S-5.15.1 - Hardware protection requirements . . . . . 92
7.1.46. S-5.16 - Hardware Finality Sink . . . . . . . . . . . 92
7.1.47. S-5.16.1 - Queue admission versus physical
execution . . . . . . . . . . . . . . . . . . . . . . 93
7.1.48. S-5.17 - CIED Variation . . . . . . . . . . . . . . . 93
7.1.49. PART V - CANDIDATE ACT AND NON-EFFECTIVE STAGING . . 93
Das Expires 25 April 2027 [Page 4]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.50. S-5.18 - Candidate Act Formation . . . . . . . . . . 93
7.1.51. S-5.19 - Non-Effective Holding . . . . . . . . . . . 94
7.1.52. S-5.19.1 - Non-blocking enforcement variation . . . . 95
7.1.53. S-5.20 - Candidate Act Descriptor . . . . . . . . . . 95
7.1.54. PART VI - PROTECTED VALIDATION . . . . . . . . . . . 96
7.1.55. S-5.21 - PED Authorization Procedure . . . . . . . . 96
7.1.56. S-5.22 - Protected Validation Evidence . . . . . . . 96
7.1.57. S-5.23 - Scoped Non-Bearer Finality Capability . . . 97
7.1.58. PART VII - FINALITY SINK VERIFICATION . . . . . . . . 97
7.1.59. S-5.24 - Finality Sink Positioning . . . . . . . . . 98
7.1.60. S-5.25 - Actual Pending Operation Reconstruction . . 98
7.1.61. S-5.25.1 - Independent source of operation
information . . . . . . . . . . . . . . . . . . . . . 99
7.1.62. S-5.26 - Sink-Local Protected State . . . . . . . . . 99
7.1.63. PART VIII - EFFECTUATION-PATH COMPLETENESS . . . . . 100
7.1.64. S-5.27 - Effectuation-Path Enumeration . . . . . . . 100
7.1.65. S-5.28 - Enforcement-Path Coverage State . . . . . . 100
7.1.66. S-5.28.1 - Configuration changes . . . . . . . . . . 101
7.1.67. PART IX - PRINCIPAL EXECUTION WORKFLOW . . . . . . . 101
7.1.68. S-5.29 - Complete 24-Step Workflow . . . . . . . . . 101
7.1.69. Step S5-01 - Execution environment initialization . . 101
7.1.70. Step S5-02 - Trust-boundary configuration . . . . . . 101
7.1.71. Step S5-03 - Kernel or hypervisor enforcement
activation . . . . . . . . . . . . . . . . . . . . . 101
7.1.72. Step S5-04 - Effectuation-path coverage
verification . . . . . . . . . . . . . . . . . . . . 101
7.1.73. Step S5-05 - Agent execution-context registration . . 101
7.1.74. Step S5-06 - Agent computation . . . . . . . . . . . 102
7.1.75. Step S5-07 - Consequential operation generation . . . 102
7.1.76. Step S5-08 - Operation interception . . . . . . . . . 102
7.1.77. Step S5-09 - Origin authentication . . . . . . . . . 102
7.1.78. Step S5-10 - Candidate Act construction . . . . . . . 102
7.1.79. Step S5-11 - Non-effective staging . . . . . . . . . 102
7.1.80. Step S5-12 - Descriptor canonicalization . . . . . . 102
7.1.81. Step S5-13 - Protected-domain submission . . . . . . 102
7.1.82. Step S5-14 - Protected authority-state retrieval . . 102
7.1.83. Step S5-15 - Predicate evaluation . . . . . . . . . . 102
7.1.84. Step S5-16 - Evidence commitment . . . . . . . . . . 102
7.1.85. Step S5-17 - Bounded capability activation . . . . . 103
7.1.86. Step S5-18 - Finality Sink presentation . . . . . . . 103
7.1.87. Step S5-19 - Actual-operation reconstruction . . . . 103
7.1.88. Step S5-20 - Finality verification . . . . . . . . . 103
7.1.89. Step S5-21 - Protected authorization-state
transition . . . . . . . . . . . . . . . . . . . . . 103
7.1.90. Step S5-22 - Controlled effectuation . . . . . . . . 103
7.1.91. Step S5-23 - Completion-state observation . . . . . . 103
7.1.92. Step S5-24 - Recovery-state reconciliation . . . . . 103
7.1.93. PART X - REPRESENTATIVE ALGORITHMS . . . . . . . . . 103
Das Expires 25 April 2027 [Page 5]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.94. S-5.30 - Algorithm A: Enforcement Initialization . . 103
7.1.95. S-5.32 - Algorithm C: Protected Validation . . . . . 105
7.1.96. S-5.33 - Algorithm D: Finality Sink Enforcement . . . 106
7.1.97. PART XI - WORKED TECHNICAL EXAMPLES . . . . . . . . . 109
7.1.98. S-5.39 - Example D: Hardware Command Queue . . . . . 110
7.1.99. PART XII - FAILURE AND ADVERSARIAL SCENARIOS . . . . 112
7.1.100. S-5.41 - Representative Failure Cases . . . . . . . 112
7.1.101. F1 - Uncontrolled System-Call Path . . . . . . . . . 112
7.1.102. F2 - Kernel Hook Not Supporting Required
Mediation . . . . . . . . . . . . . . . . . . . . . . 112
7.1.103. F3 - eBPF Observation Without Enforcement . . . . . 112
7.1.104. F4 - Unauthorized Enforcement-Program Removal . . . 112
7.1.105. F5 - Kernel-Level Compromise . . . . . . . . . . . . 112
7.1.106. F6 - Guest Kernel Compromise . . . . . . . . . . . . 113
7.1.107. F7 - Device Pass-Through . . . . . . . . . . . . . . 113
7.1.108. F8 - Memory Modification After Validation . . . . . 113
7.1.109. F9 - Resource Identifier Substitution . . . . . . . 113
7.1.110. F10 - Authority Generation Mismatch . . . . . . . . 113
7.1.111. F11 - Capability Replay . . . . . . . . . . . . . . 113
7.1.112. F12 - Concurrent Capability Use . . . . . . . . . . 113
7.1.113. F13 - Hardware Queue Already Contains Commands . . . 114
7.1.114. F14 - Hypervisor Backend Replacement . . . . . . . . 114
7.1.115. F15 - Kernel Policy Reload . . . . . . . . . . . . . 114
7.1.116. F16 - PED Unavailability . . . . . . . . . . . . . . 114
7.1.117. F17 - Finality Sink Failure . . . . . . . . . . . . 114
7.1.118. F18 - Protected State Rollback . . . . . . . . . . . 114
7.1.119. F19 - Asynchronous Worker Continuation . . . . . . . 115
7.1.120. F20 - Indeterminate External Completion . . . . . . 115
7.1.121. F21 - Kernel Resource Exhaustion . . . . . . . . . . 115
7.1.122. F22 - Hypervisor Migration . . . . . . . . . . . . . 115
7.1.123. F23 - Protected Credential Path Bypass . . . . . . . 115
7.1.124. F24 - Inconsistent Multi-Sink Revocation . . . . . . 115
7.1.125. PART XIII - SOFTWARE, FIRMWARE, HARDWARE, AND
DISTRIBUTED VARIATIONS . . . . . . . . . . . . . . . 116
7.1.126. S-5.42 - Kernel-Only Software Implementation . . . . 116
7.1.127. S-5.43 - Hypervisor-Only Enforcement
Implementation . . . . . . . . . . . . . . . . . . . 116
7.1.128. S-5.44 - Kernel and Hypervisor Cooperative
Implementation . . . . . . . . . . . . . . . . . . . 116
7.1.129. S-5.45 - TEE-Backed PED Implementation . . . . . . . 117
7.1.130. S-5.46 - HSM-Backed Enforcement Implementation . . . 117
7.1.131. S-5.49 - Accelerator and DMA Enforcement
Implementation . . . . . . . . . . . . . . . . . . . 117
7.1.132. S-5.50 - Distributed PED and Finality Sink . . . . . 117
7.1.133. S-5.51 - Colocated PED and Finality Sink . . . . . . 118
7.1.134. PART XIV - TECHNICAL DATA STRUCTURES . . . . . . . . 118
7.1.135. S-5.52 - ExecutionContextRecord . . . . . . . . . . 118
7.1.136. S-5.53 - EnforcementPointRecord . . . . . . . . . . 118
Das Expires 25 April 2027 [Page 6]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.137. S-5.54 - CandidateActRecord . . . . . . . . . . . . 119
7.1.138. S-5.55 - ProtectedValidationEvidenceRecord . . . . . 119
7.1.139. S-5.56 - ScopedFinalityCapabilityRecord . . . . . . 119
7.1.140. S-5.57 - SinkLocalStateRecord . . . . . . . . . . . 119
7.1.141. S-5.58 - EffectuationPathCoverageRecord . . . . . . 119
7.1.142. S-5.59 - HardwareOperationRecord . . . . . . . . . . 120
7.1.143. S-5.60 - RecoveryStateRecord . . . . . . . . . . . . 120
7.1.144. PART XV - implementer VERIFICATION TESTS . . . . . . 120
7.1.145. S-5.61 - Representative Engineering Verification
Procedures . . . . . . . . . . . . . . . . . . . . . 120
7.1.146. Test Technical condition . . . . . . . . . . . . . . 120
7.1.147. Expected behavior . . . . . . . . . . . . . . . . . 121
7.1.148. PART XVI - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 121
7.1.149. S-5.62 - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 121
7.1.150. PART XVII - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 122
7.1.151. S-5.63 - Complete Implementation Checklist . . . . . 122
7.1.152. S-5.64 - Technical Effect . . . . . . . . . . . . . 123
7.2. Implementation Profile S-7 . . . . . . . . . . . . . . . 125
7.2.1. S-7.1 - Technical Field . . . . . . . . . . . . . . . 125
7.2.2. S-7.2 - Technical Problem . . . . . . . . . . . . . . 126
7.2.3. S-7.3 - Technical Objectives . . . . . . . . . . . . 127
7.2.4. PART I - PRINCIPAL ARCHITECTURE . . . . . . . . . . . 128
7.2.5. S-7.4 - Principal Components . . . . . . . . . . . . 128
7.2.6. Component A - Computing Platform . . . . . . . . . . 128
7.2.7. Component B - Agent Execution Environment . . . . . . 128
7.2.8. Component C - Hardware Root of Trust . . . . . . . . 128
7.2.9. Component D - Protected Execution Controller . . . . 129
7.2.10. Component E - Protected Enforcement Domain . . . . . 129
7.2.11. Component F - Cryptographically Isolated Enforcement
Domain . . . . . . . . . . . . . . . . . . . . . . . 129
7.2.12. Component G - Protected Key Custody Controller . . . 129
7.2.13. Component H - Attestation and Measurement
Controller . . . . . . . . . . . . . . . . . . . . . 129
7.2.14. Component I - Candidate Act Interceptor . . . . . . . 129
7.2.15. Component J - Non-Effective Operation Holder . . . . 129
7.2.16. Component K - Protected Authority-State Controller . 129
7.2.17. Component L - Protected Validation Controller . . . . 129
7.2.18. Component M - Validation Evidence Commitment
Controller . . . . . . . . . . . . . . . . . . . . . 130
7.2.19. Component N - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 130
7.2.20. Component O - Finality Sink . . . . . . . . . . . . . 130
7.2.21. Component P - Protected State Continuity
Controller . . . . . . . . . . . . . . . . . . . . . 130
7.2.22. Component Q - Controlled Communication Interface . . 130
Das Expires 25 April 2027 [Page 7]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.23. Component R - Recovery and Revocation Controller . . 130
7.2.24. S-7.5 - Reference Deployment . . . . . . . . . . . . 130
7.2.25. PART II - HARDWARE ROOT OF TRUST . . . . . . . . . . 131
7.2.26. S-7.6 - Hardware Root of Trust . . . . . . . . . . . 131
7.2.27. S-7.7 - Hardware-Rooted Identity . . . . . . . . . . 131
7.2.28. S-7.8 - Secure Boot and Measured Boot . . . . . . . . 132
7.2.29. PART III - TRUSTED EXECUTION ENVIRONMENTS . . . . . . 132
7.2.30. S-7.9 - TEE Execution Domain . . . . . . . . . . . . 132
7.2.31. S-7.10 - TEE-Resident PED . . . . . . . . . . . . . . 133
7.2.32. S-7.10.1 - Protected executable logic . . . . . . . . 133
7.2.33. S-7.11 - TEE-Resident Agent . . . . . . . . . . . . . 134
7.2.34. S-7.12 - Compartmentalized TEE . . . . . . . . . . . 134
7.2.35. PART IV - HARDWARE SECURITY MODULES . . . . . . . . . 135
7.2.36. S-7.13 - HSM-Based Protected Authority . . . . . . . 135
7.2.37. S-7.14 - Protected Key Custody . . . . . . . . . . . 135
7.2.38. S-7.14.1 - Separation of key purposes . . . . . . . . 136
7.2.39. S-7.15 - Protection Against Unrestricted Signing . . 136
7.2.40. S-7.16 - HSM-Based Cryptographic Finality Sink . . . 136
7.2.41. PART V - PED AND CIED RELATIONSHIP . . . . . . . . . 137
7.2.42. S-7.17 - PED as Functional Enforcement Domain . . . . 137
7.2.43. S-7.18 - CIED as Cryptographically Protected PED . . 137
7.2.44. S-7.19 - PED/CIED Physical Co-Location . . . . . . . 138
7.2.45. PART VI - ATTESTATION . . . . . . . . . . . . . . . . 138
7.2.46. S-7.20 - Protected Measurement . . . . . . . . . . . 138
7.2.47. S-7.21 - Attestation Evidence . . . . . . . . . . . . 139
7.2.48. S-7.22 - Attestation Verifier . . . . . . . . . . . . 139
7.2.49. S-7.23 - Attestation and Operation Authorization . . 140
7.2.50. S-7.24 - Attestation-to-Session Binding . . . . . . . 140
7.2.51. PART VII - PROTECTED MUTABLE STATE . . . . . . . . . 141
7.2.52. S-7.25 - Protected Authority State . . . . . . . . . 141
7.2.53. S-7.26 - Protected-State Integrity . . . . . . . . . 141
7.2.54. S-7.27 - Protected State Transition . . . . . . . . . 141
7.2.55. PART VIII - ROLLBACK RESISTANCE . . . . . . . . . . . 142
7.2.56. S-7.28 - State Rollback Threat . . . . . . . . . . . 142
7.2.57. S-7.29 - Anti-Rollback State Anchor . . . . . . . . . 142
7.2.58. S-7.30 - Protected State Recovery . . . . . . . . . . 143
7.2.59. PART IX - CANDIDATE ACT STAGING . . . . . . . . . . . 143
7.2.60. S-7.31 - Candidate Act Capture . . . . . . . . . . . 143
7.2.61. S-7.32 - Non-Effective Operation Holding . . . . . . 144
7.2.62. S-7.33 - Candidate Act Descriptor . . . . . . . . . . 144
7.2.63. PART X - PROTECTED VALIDATION . . . . . . . . . . . . 145
7.2.64. S-7.34 - Protected Authorization Procedure . . . . . 145
7.2.65. S-7.35 - Protected Validation Evidence . . . . . . . 145
7.2.66. S-7.36 - Evidence Commitment Ordering . . . . . . . . 146
7.2.67. PART XI - SCOPED NON-BEARER FINALITY CAPABILITY . . . 146
7.2.68. S-7.37 - Protected Finality Capability . . . . . . . 146
7.2.69. S-7.38 - Hardware Capability Representations . . . . 147
7.2.70. S-7.39 - Capability Anti-Replay . . . . . . . . . . . 147
Das Expires 25 April 2027 [Page 8]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.71. PART XII - FINALITY SINK IMPLEMENTATION . . . . . . . 148
7.2.72. S-7.40 - Hardware or Software Finality Sink . . . . . 148
7.2.73. S-7.41 - Independent Actual-Operation Verification . 148
7.2.74. S-7.42 - Remote Finality Sink . . . . . . . . . . . . 149
7.2.75. S-7.43 - Non-Bypassability . . . . . . . . . . . . . 150
7.2.76. PART XIII - PROTECTED CROSS-COMMITTED EVIDENCE
VARIATION . . . . . . . . . . . . . . . . . . . . . . 150
7.2.77. S-7.44 - Two Protected Validation Instances . . . . . 150
7.2.78. S-7.45 - Cross-Commitment Representation . . . . . . 150
7.2.79. S-7.46 - Sink Verification of Cross-Committed
Evidence . . . . . . . . . . . . . . . . . . . . . . 151
7.2.80. PART XIV - PRINCIPAL ENABLEMENT WORKFLOW . . . . . . 151
7.2.81. S-7.47 - Complete 30-Step Successful Execution
Workflow . . . . . . . . . . . . . . . . . . . . . . 151
7.2.82. Step S7-01 - Hardware security initialization . . . . 151
7.2.83. Step S7-02 - Protected component authentication . . . 151
7.2.84. Step S7-03 - Protected executable-state
verification . . . . . . . . . . . . . . . . . . . . 152
7.2.85. Step S7-04 - Protected key establishment . . . . . . 152
7.2.86. Step S7-05 - Protected authority-state recovery . . . 152
7.2.87. Step S7-06 - State-continuity verification . . . . . 152
7.2.88. Step S7-07 - Attestation . . . . . . . . . . . . . . 152
7.2.89. Step S7-08 - Secure communication establishment . . . 152
7.2.90. Step S7-09 - Agent execution-context registration . . 152
7.2.91. Step S7-10 - Effectuation-path verification . . . . . 152
7.2.92. Step S7-11 - Agent computation . . . . . . . . . . . 152
7.2.93. Step S7-12 - Consequential operation proposal . . . . 152
7.2.94. Step S7-13 - Candidate Act capture . . . . . . . . . 153
7.2.95. Step S7-14 - Non-effective staging . . . . . . . . . 153
7.2.96. Step S7-15 - Descriptor canonicalization . . . . . . 153
7.2.97. Step S7-16 - CIED submission . . . . . . . . . . . . 153
7.2.98. Step S7-17 - Protected authority-state acquisition . 153
7.2.99. Step S7-18 - Protected predicate evaluation . . . . . 153
7.2.100. Step S7-19 - Optional independent validation . . . . 153
7.2.101. Step S7-20 - Protected evidence commitment . . . . . 153
7.2.102. Step S7-21 - Optional cross-commitment . . . . . . . 153
7.2.103. Step S7-22 - Scoped capability establishment . . . . 153
7.2.104. Step S7-23 - Capability delivery or protected
reference activation . . . . . . . . . . . . . . . . 154
7.2.105. Step S7-24 - Actual pending operation acquisition . 154
7.2.106. Step S7-25 - Evidence verification . . . . . . . . . 154
7.2.107. Step S7-26 - Capability and actual-operation
verification . . . . . . . . . . . . . . . . . . . . 154
7.2.108. Step S7-27 - Protected consumption transition . . . 154
7.2.109. Step S7-28 - Controlled effectuation . . . . . . . . 154
7.2.110. Step S7-29 - Completion observation . . . . . . . . 154
7.2.111. Step S7-30 - Protected state reconciliation . . . . 154
7.2.112. PART XV - REFERENCE ALGORITHMS . . . . . . . . . . . 154
Das Expires 25 April 2027 [Page 9]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.113. S-7.49 - Algorithm B: Attestation Appraisal . . . . 155
7.2.114. S-7.50 - Algorithm C: Protected CIED Validation . . 156
7.2.115. S-7.53 - Algorithm F: Rollback-Resistant Recovery . 159
7.2.116. S-7.54 - Algorithm G: Secure Capability
Revocation . . . . . . . . . . . . . . . . . . . . . 160
7.2.117. S-7.55 - Algorithm H: Protected Key-Use Finality . . 161
7.2.118. PART XVI - WORKED TECHNICAL EXAMPLES . . . . . . . . 161
7.2.119. S-7.57 - Example B: TEE-Protected Network Egress . . 162
7.2.120. PART XVII - FAILURE AND ADVERSARIAL CASES . . . . . 165
7.2.121. S-7.62 - Representative Failure Conditions . . . . . 165
7.2.122. F1 - Unauthorized TEE Call . . . . . . . . . . . . . 165
7.2.123. F2 - HSM Signing Oracle . . . . . . . . . . . . . . 165
7.2.124. F3 - Attestation Replay . . . . . . . . . . . . . . 166
7.2.125. F4 - Attestation Substitution . . . . . . . . . . . 166
7.2.126. F5 - Compromised Host Software . . . . . . . . . . . 166
7.2.127. F6 - Protected-State Tampering . . . . . . . . . . . 166
7.2.128. F7 - Sealed-State Rollback . . . . . . . . . . . . . 166
7.2.129. F8 - Capability Replay . . . . . . . . . . . . . . . 166
7.2.130. F9 - Capability Substitution . . . . . . . . . . . . 166
7.2.131. F10 - Sink Substitution . . . . . . . . . . . . . . 167
7.2.132. F11 - Resource Substitution . . . . . . . . . . . . 167
7.2.133. F12 - Signing-Payload Substitution . . . . . . . . . 167
7.2.134. F13 - Key Extraction Attempt . . . . . . . . . . . . 167
7.2.135. F14 - Key-Use Policy Bypass . . . . . . . . . . . . 167
7.2.136. F15 - CIED Restart . . . . . . . . . . . . . . . . . 167
7.2.137. F16 - HSM Replacement . . . . . . . . . . . . . . . 167
7.2.138. F17 - Protected Counter Exhaustion . . . . . . . . . 168
7.2.139. F18 - Protected Storage Unavailable . . . . . . . . 168
7.2.140. F19 - Expired Attestation . . . . . . . . . . . . . 168
7.2.141. F20 - Security-Version Rollback . . . . . . . . . . 168
7.2.142. F21 - Concurrent Capability Use . . . . . . . . . . 168
7.2.143. F22 - Remote State Inconsistency . . . . . . . . . . 168
7.2.144. F23 - Network Partition . . . . . . . . . . . . . . 169
7.2.145. F24 - Hardware Queue Already Admitted . . . . . . . 169
7.2.146. F25 - Side-Channel Exposure . . . . . . . . . . . . 169
7.2.147. F26 - Physical Hardware Attack . . . . . . . . . . . 169
7.2.148. F27 - Firmware Compromise . . . . . . . . . . . . . 169
7.2.149. F28 - Alternative Effectuation Path . . . . . . . . 169
7.2.150. F29 - Incomplete Protected Transition . . . . . . . 170
7.2.151. F30 - Indeterminate External Completion . . . . . . 170
7.2.152. F31 - Incorrect Canonicalization . . . . . . . . . . 170
7.2.153. F32 - Unauthorized Protected Policy Update . . . . . 170
7.2.154. PART XVIII - HARDWARE, SOFTWARE, AND DISTRIBUTED
VARIATIONS . . . . . . . . . . . . . . . . . . . . . 170
7.2.155. S-7.63 - TEE-Based PED with Software Finality
Sink . . . . . . . . . . . . . . . . . . . . . . . . 170
7.2.156. S-7.67 - Confidential Virtual Machine
Implementation . . . . . . . . . . . . . . . . . . . 171
Das Expires 25 April 2027 [Page 10]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.157. S-7.68 - SmartNIC/DPU CIED Implementation . . . . . 171
7.2.158. S-7.69 - Secure Accelerator Implementation . . . . . 171
7.2.159. S-7.70 - Distributed CIED Implementation . . . . . . 172
7.2.160. S-7.71 - Single-Chip Integrated Finality
Implementation . . . . . . . . . . . . . . . . . . . 172
7.2.161. S-7.72 - Cross-Device Protected Authorization . . . 172
7.2.162. PART XIX - REPRESENTATIVE TECHNICAL DATA
STRUCTURES . . . . . . . . . . . . . . . . . . . . . 173
7.2.163. S-7.73 - ProtectedExecutionContextRecord . . . . . . 173
7.2.164. S-7.74 - AttestationEvidenceRecord . . . . . . . . . 173
7.2.165. S-7.75 - ProtectedAuthorityStateRecord . . . . . . . 173
7.2.166. S-7.76 - CandidateActRecord . . . . . . . . . . . . 173
7.2.167. S-7.77 - ProtectedValidationEvidenceRecord . . . . . 174
7.2.168. S-7.78 - ScopedFinalityCapabilityRecord . . . . . . 174
7.2.169. S-7.79 - SinkLocalProtectedStateRecord . . . . . . . 174
7.2.170. S-7.80 - ProtectedStateContinuityRecord . . . . . . 174
7.2.171. S-7.81 - CrossCommitmentRecord . . . . . . . . . . . 174
7.2.172. S-7.82 - ProtectedHardwareOperationRecord . . . . . 175
7.2.173. PART XX - implementer ENGINEERING VERIFICATION . . . 175
7.2.174. S-7.83 - Representative Verification Tests . . . . . 175
7.2.175. Test Condition . . . . . . . . . . . . . . . . . . . 175
7.2.176. Expected technical behavior . . . . . . . . . . . . 175
7.2.177. PART XXI - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 176
7.2.178. S-7.84 - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 176
7.2.179. PART XXII - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 177
7.2.180. S-7.85 - Implementation Checklist . . . . . . . . . 177
7.2.181. S-7.86 - Technical Effect . . . . . . . . . . . . . 178
7.2.182. S-7.87 - Technical Summary . . . . . . . . . . . . . 179
7.3. Implementation Profile S-8 . . . . . . . . . . . . . . . 180
7.3.1. S-8.1 - Technical Field . . . . . . . . . . . . . . . 180
7.3.2. S-8.2 - Technical Problem . . . . . . . . . . . . . . 181
7.3.3. S-8.3 - Technical Objectives . . . . . . . . . . . . 183
7.3.4. PART I - GENERAL HARDWARE-SOFTWARE ARCHITECTURE . . . 183
7.3.5. S-8.4 - Principal Components . . . . . . . . . . . . 184
7.3.6. Component A - Host Computing Platform . . . . . . . . 184
7.3.7. Component B - Agent Execution Runtime . . . . . . . . 184
7.3.8. Component C - Device and Resource Manager . . . . . . 184
7.3.9. Component D - Hardware Isolation Controller . . . . . 184
7.3.10. Component E - IOMMU or Equivalent Memory-Access
Controller . . . . . . . . . . . . . . . . . . . . . 184
7.3.11. Component F - DMA Operation Controller . . . . . . . 184
7.3.12. Component G - Accelerator Execution Controller . . . 184
7.3.13. Component H - SmartNIC/DPU Controller . . . . . . . . 184
7.3.14. Component I - Hardware Command Interceptor . . . . . 185
7.3.15. Component J - Non-Effective Command Holder . . . . . 185
Das Expires 25 April 2027 [Page 11]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.16. Component K - Protected Enforcement Domain . . . . . 185
7.3.17. Component L - Cryptographically Isolated Enforcement
Domain . . . . . . . . . . . . . . . . . . . . . . . 185
7.3.18. Component M - Protected Evidence Controller . . . . . 185
7.3.19. Component N - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 185
7.3.20. Component O - Hardware or Software Finality Sink . . 185
7.3.21. Component P - Device Authority-Generation
Controller . . . . . . . . . . . . . . . . . . . . . 185
7.3.22. Component Q - Command Queue and Completion
Controller . . . . . . . . . . . . . . . . . . . . . 185
7.3.23. Component R - Hardware Fencing Controller . . . . . . 186
7.3.24. Component S - Device Memory Ownership Controller . . 186
7.3.25. Component T - Memory Sanitization Controller . . . . 186
7.3.26. Component U - Device Recovery and Reconciliation
Controller . . . . . . . . . . . . . . . . . . . . . 186
7.3.27. S-8.5 - Reference Deployment . . . . . . . . . . . . 186
7.3.28. PART II - HARDWARE ISOLATION DEFINITIONS . . . . . . 187
7.3.29. S-8.6 - Hardware-Isolated Execution Environment . . . 187
7.3.30. S-8.7 - Accelerator Execution Domain . . . . . . . . 187
7.3.31. S-8.8 - Device Authority Domain . . . . . . . . . . . 188
7.3.32. PART III - GPU AND AI ACCELERATOR EXECUTION . . . . . 188
7.3.33. S-8.9 - GPU Execution Context . . . . . . . . . . . . 188
7.3.34. S-8.10 - AI Accelerator Sandbox . . . . . . . . . . . 189
7.3.35. S-8.11 - Agent-Originated Accelerator Operation . . . 189
7.3.36. S-8.12 - Computation Versus Consequential Output . . 190
7.3.37. PART IV - GPU COMMAND SUBMISSION AND FINALITY . . . . 191
7.3.38. S-8.13 - Hardware Command Descriptor . . . . . . . . 191
7.3.39. S-8.14 - Command Admission Boundary . . . . . . . . . 191
7.3.40. S-8.15 - Hardware Execution Boundary . . . . . . . . 192
7.3.41. S-8.16 - Device Command Finality Sink . . . . . . . . 192
7.3.42. PART V - SMARTNIC AND DPU IMPLEMENTATION . . . . . . 192
7.3.43. S-8.17 - SmartNIC/DPU Enforcement Environment . . . . 192
7.3.44. S-8.18 - SmartNIC-Based Agent Egress Finality . . . . 193
7.3.45. S-8.18.1 - Network visibility limitation . . . . . . 193
7.3.46. S-8.19 - DPU-Based Resource Control . . . . . . . . . 194
7.3.47. PART VI - IOMMU AND DMA ISOLATION . . . . . . . . . . 194
7.3.48. S-8.20 - Direct Memory Access . . . . . . . . . . . . 194
7.3.49. S-8.21 - IOMMU Enforcement Domain . . . . . . . . . . 195
7.3.50. S-8.22 - DMA Permission Versus Operation
Authorization . . . . . . . . . . . . . . . . . . . . 195
7.3.51. S-8.23 - DMA Effectuation Boundary . . . . . . . . . 196
7.3.52. S-8.24 - DMA Mapping Lifetime . . . . . . . . . . . . 196
7.3.53. S-8.25 - Translation Invalidation . . . . . . . . . . 196
7.3.54. PART VII - CROSS-DEVICE MEMORY ACCESS . . . . . . . . 197
7.3.55. S-8.26 - Peer-to-Peer Device Transfer . . . . . . . . 197
7.3.56. S-8.27 - Peer-to-Peer Effectuation Control . . . . . 197
Das Expires 25 April 2027 [Page 12]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.57. PART VIII - PROTECTED HARDWARE AUTHORITY
GENERATIONS . . . . . . . . . . . . . . . . . . . . . 198
7.3.58. S-8.28 - Hardware Authority Generation . . . . . . . 198
7.3.59. S-8.29 - Generation-Bound Device Command . . . . . . 198
7.3.60. S-8.30 - Authority Generation Transition . . . . . . 199
7.3.61. PART IX - HARDWARE QUEUE FENCING . . . . . . . . . . 199
7.3.62. S-8.31 - Hardware Queue State . . . . . . . . . . . . 199
7.3.63. S-8.32 - Hardware Fencing . . . . . . . . . . . . . . 200
7.3.64. S-8.33 - Admission Fence . . . . . . . . . . . . . . 201
7.3.65. S-8.34 - Execution Fence . . . . . . . . . . . . . . 201
7.3.66. S-8.35 - Completion Watermark . . . . . . . . . . . . 202
7.3.67. S-8.36 - Quiescence . . . . . . . . . . . . . . . . . 202
7.3.68. PART X - PROTECTED COMMAND FINALITY . . . . . . . . . 203
7.3.69. S-8.37 - Candidate Hardware Act . . . . . . . . . . . 203
7.3.70. S-8.38 - Hardware Non-Effective State . . . . . . . . 203
7.3.71. S-8.39 - Hardware PED Validation . . . . . . . . . . 204
7.3.72. S-8.40 - Hardware Protected Validation Evidence . . . 204
7.3.73. S-8.41 - Hardware Scoped Finality Capability . . . . 204
7.3.74. S-8.42 - Hardware Finality Sink Verification . . . . 205
7.3.75. PART XI - MEMORY OWNERSHIP AND TENANT ISOLATION . . . 205
7.3.76. S-8.43 - Accelerator Memory Ownership . . . . . . . . 205
7.3.77. S-8.44 - Memory Ownership Transition . . . . . . . . 206
7.3.78. S-8.45 - Residual Accelerator Memory . . . . . . . . 206
7.3.79. PART XII - VERIFIED MEMORY SANITIZATION . . . . . . . 207
7.3.80. S-8.46 - Memory Sanitization Controller . . . . . . . 207
7.3.81. S-8.47 - Sanitization Preconditions . . . . . . . . . 207
7.3.82. S-8.48 - Sanitization Procedure . . . . . . . . . . . 208
7.3.83. S-8.49 - Sanitization Verification . . . . . . . . . 209
7.3.84. S-8.50 - Cryptographic Erasure Variation . . . . . . 209
7.3.85. PART XIII - CROSS-DEVICE REVOCATION . . . . . . . . . 209
7.3.86. S-8.51 - Multi-Device Authority Context . . . . . . . 210
7.3.87. S-8.52 - Cross-Device Authority Generation . . . . . 210
7.3.88. S-8.53 - Distributed Hardware Fencing . . . . . . . . 210
7.3.89. S-8.54 - Cross-Device Completion Watermark . . . . . 211
7.3.90. PART XIV - PRINCIPAL EXECUTION WORKFLOW . . . . . . . 211
7.3.91. S-8.55 - Complete 32-Step Hardware Finality
Workflow . . . . . . . . . . . . . . . . . . . . . . 211
7.3.92. Step S8-01 - Hardware resource initialization . . . . 211
7.3.93. Step S8-02 - Device security configuration . . . . . 212
7.3.94. Step S8-03 - Device identity establishment . . . . . 212
7.3.95. Step S8-04 - Authority-generation initialization . . 212
7.3.96. Step S8-05 - Execution-context registration . . . . . 212
7.3.97. Step S8-06 - Memory ownership configuration . . . . . 212
7.3.98. Step S8-07 - DMA access configuration . . . . . . . . 212
7.3.99. Step S8-08 - Command-interface control . . . . . . . 212
7.3.100. Step S8-09 - Effectuation-path verification . . . . 212
7.3.101. Step S8-10 - Agent computation . . . . . . . . . . . 212
7.3.102. Step S8-11 - Hardware operation proposal . . . . . . 212
Das Expires 25 April 2027 [Page 13]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.103. Step S8-12 - Operation interception . . . . . . . . 213
7.3.104. Step S8-13 - Candidate Hardware Act construction . . 213
7.3.105. Step S8-14 - Non-effective command staging . . . . . 213
7.3.106. Step S8-15 - Actual device-context association . . . 213
7.3.107. Step S8-16 - Descriptor canonicalization . . . . . . 213
7.3.108. Step S8-17 - PED submission . . . . . . . . . . . . 213
7.3.109. Step S8-18 - Protected authority-state retrieval . . 213
7.3.110. Step S8-19 - Required predicate evaluation . . . . . 213
7.3.111. Step S8-20 - Protected validation evidence
commitment . . . . . . . . . . . . . . . . . . . . . 213
7.3.112. Step S8-21 - Scoped finality capability
establishment . . . . . . . . . . . . . . . . . . . . 213
7.3.113. Step S8-22 - Command presentation . . . . . . . . . 213
7.3.114. Step S8-23 - Actual pending command
reconstruction . . . . . . . . . . . . . . . . . . . 214
7.3.115. Step S8-24 - Capability verification . . . . . . . . 214
7.3.116. Step S8-25 - Authority-generation verification . . . 214
7.3.117. Step S8-26 - Memory-access verification . . . . . . 214
7.3.118. Step S8-27 - Protected consumption transition . . . 214
7.3.119. Step S8-28 - Hardware command admission . . . . . . 214
7.3.120. Step S8-29 - Hardware execution . . . . . . . . . . 214
7.3.121. Step S8-30 - Completion observation . . . . . . . . 214
7.3.122. Step S8-31 - Effectuation outcome reconciliation . . 214
7.3.123. Step S8-32 - Resource lifecycle update . . . . . . . 214
7.3.124. PART XV - REFERENCE ALGORITHMS . . . . . . . . . . . 215
7.3.125. S-8.57 - Algorithm B: Hardware Command Capture . . . 215
7.3.126. S-8.59 - Algorithm D: Hardware Finality Sink . . . . 217
7.3.127. S-8.61 - Algorithm F: DMA Access Revocation . . . . 220
7.3.128. S-8.63 - Algorithm H: Hardware Recovery . . . . . . 222
7.3.129. PART XVI - WORKED TECHNICAL EXAMPLES . . . . . . . . 223
7.3.130. S-8.66 - Example C: DMA Isolation of Agent Memory . 224
7.3.131. S-8.70 - Example G: Cross-Device Revocation . . . . 227
7.3.132. PART XVII - FAILURE AND ADVERSARIAL SCENARIOS . . . 228
7.3.133. S-8.72 - Representative Failure Conditions . . . . . 228
7.3.134. F1 - Uncontrolled GPU Command Queue . . . . . . . . 228
7.3.135. F2 - Device Command Substitution . . . . . . . . . . 228
7.3.136. F3 - Stale Authority Generation . . . . . . . . . . 228
7.3.137. F4 - Stale Ownership Generation . . . . . . . . . . 228
7.3.138. F5 - IOMMU Mapping Error . . . . . . . . . . . . . . 228
7.3.139. F6 - DMA Translation Staleness . . . . . . . . . . . 228
7.3.140. F7 - In-Flight DMA After Revocation . . . . . . . . 229
7.3.141. F8 - GPU Memory Reuse Without Sanitization . . . . . 229
7.3.142. F9 - Sanitization Before Queue Drain . . . . . . . . 229
7.3.143. F10 - Incomplete Sanitization Coverage . . . . . . . 229
7.3.144. F11 - Unverified Cryptographic Erasure . . . . . . . 229
7.3.145. F12 - Peer-to-Peer Bypass . . . . . . . . . . . . . 229
7.3.146. F13 - Unauthorized Device Pass-Through . . . . . . . 230
7.3.147. F14 - Firmware Authorization Bypass . . . . . . . . 230
Das Expires 25 April 2027 [Page 14]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.148. F15 - Capability Replay . . . . . . . . . . . . . . 230
7.3.149. F16 - Concurrent Capability Use . . . . . . . . . . 230
7.3.150. F17 - Device Reset Clears Revocation State . . . . . 230
7.3.151. F18 - Queue Completion Misinterpretation . . . . . . 230
7.3.152. F19 - Cross-Device Generation Mismatch . . . . . . . 230
7.3.153. F20 - Command Cancellation Unsupported . . . . . . . 231
7.3.154. F21 - Hardware Quiescence Misclassification . . . . 231
7.3.155. F22 - Protected Register Tampering . . . . . . . . . 231
7.3.156. F23 - Device Identity Substitution . . . . . . . . . 231
7.3.157. F24 - Queue Identity Substitution . . . . . . . . . 231
7.3.158. F25 - Hardware Command Parameter Expansion . . . . . 231
7.3.159. F26 - GPU Context Reuse . . . . . . . . . . . . . . 232
7.3.160. F27 - Cross-Tenant Resource Alias . . . . . . . . . 232
7.3.161. F28 - Device Firmware Downgrade . . . . . . . . . . 232
7.3.162. F29 - Host-Kernel Compromise . . . . . . . . . . . . 232
7.3.163. F30 - Device Controller Compromise . . . . . . . . . 232
7.3.164. F31 - Hardware Queue Resource Exhaustion . . . . . . 232
7.3.165. F32 - Memory Ownership Registry Rollback . . . . . . 233
7.3.166. F33 - Device Hot-Plug or Removal . . . . . . . . . . 233
7.3.167. F34 - Accelerator Migration . . . . . . . . . . . . 233
7.3.168. F35 - External Operation Acknowledgment Lost . . . . 233
7.3.169. F36 - Protected State Recovery Failure . . . . . . . 233
7.3.170. PART XVIII - IMPLEMENTATION VARIATIONS . . . . . . . 233
7.3.171. S-8.73 - GPU-Only Resource Isolation . . . . . . . . 233
7.3.172. S-8.74 - GPU With Software PED . . . . . . . . . . . 234
7.3.173. S-8.77 - DPU and GPU Cooperative Enforcement . . . . 234
7.3.174. S-8.78 - FPGA-Based Enforcement . . . . . . . . . . 234
7.3.175. S-8.79 - ASIC-Based Finality Controller . . . . . . 234
7.3.176. S-8.80 - IOMMU-Based Memory Isolation . . . . . . . 234
7.3.177. S-8.81 - Cross-Device Protected Controller . . . . . 235
7.3.178. S-8.82 - Device Memory Sanitization Without Finality
Capability . . . . . . . . . . . . . . . . . . . . . 235
7.3.179. PART XIX - TECHNICAL DATA STRUCTURES . . . . . . . . 235
7.3.180. S-8.86 - HardwareExecutionContextRecord . . . . . . 235
7.3.181. S-8.87 - DeviceAuthorityRecord . . . . . . . . . . . 236
7.3.182. S-8.88 - HardwareCandidateActRecord . . . . . . . . 236
7.3.183. S-8.89 - HardwareValidationEvidenceRecord . . . . . 236
7.3.184. S-8.90 - HardwareFinalityCapabilityRecord . . . . . 236
7.3.185. S-8.91 - DeviceQueueStateRecord . . . . . . . . . . 236
7.3.186. S-8.92 - DMAAccessRecord . . . . . . . . . . . . . . 237
7.3.187. S-8.93 - DeviceMemoryOwnershipRecord . . . . . . . . 237
7.3.188. S-8.94 - SanitizationEvidenceRecord . . . . . . . . 237
7.3.189. S-8.95 - CrossDeviceFencingRecord . . . . . . . . . 237
7.3.190. S-8.96 - HardwareRecoveryRecord . . . . . . . . . . 237
7.3.191. PART XX - implementer VERIFICATION TESTS . . . . . . 238
7.3.192. S-8.97 - Representative Engineering Test Matrix . . 238
7.3.193. PART XXI - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 239
Das Expires 25 April 2027 [Page 15]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.194. S-8.98 - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 239
7.3.195. PART XXII - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 240
7.3.196. S-8.99 - Hardware Implementation Checklist . . . . . 241
7.3.197. PART XXIII - TECHNICAL EFFECT . . . . . . . . . . . 242
7.3.198. S-8.100 - Technical Effect . . . . . . . . . . . . . 242
7.4. Implementation Profile C-09 . . . . . . . . . . . . . . . 243
7.4.1. C-09.1 - Technical Field . . . . . . . . . . . . . . 243
7.4.2. C-09.2 - Technical Problem . . . . . . . . . . . . . 244
7.4.3. C-09.3 - Central Technical Principle . . . . . . . . 245
7.4.4. PART I - PRINCIPAL ARCHITECTURE . . . . . . . . . . . 246
7.4.5. C-09.4 - Principal Components . . . . . . . . . . . . 246
7.4.6. Component A - Artificial-Intelligence-Agent Execution
Environment . . . . . . . . . . . . . . . . . . . . . 246
7.4.7. Component B - Operation Submission Interface . . . . 246
7.4.8. Component C - Inline Effectuation Controller . . . . 246
7.4.9. Component D - Candidate Transaction Holder . . . . . 246
7.4.10. Component E - Actual-Operation Descriptor
Generator . . . . . . . . . . . . . . . . . . . . . . 246
7.4.11. Component F - Protected Authority-State Store . . . . 246
7.4.12. Component G - Protected Predicate Evaluator . . . . . 246
7.4.13. Component H - Protected Validation-State Store . . . 247
7.4.14. Component I - Inline Enablement Controller . . . . . 247
7.4.15. Component J - Native Resource Controller . . . . . . 247
7.4.16. Component K - Protected Consumption Controller . . . 247
7.4.17. Component L - Transaction Recovery Controller . . . . 247
7.4.18. C-09.5 - Integrated Effectuation Controller . . . . . 247
7.4.19. PART II - OPERATION AND RESOURCE REPRESENTATION . . . 248
7.4.20. C-09.6 - Candidate Inline Transaction . . . . . . . . 248
7.4.21. C-09.7 - Candidate Transaction Descriptor . . . . . . 248
7.4.22. C-09.8 - Actual-Operation Reconstruction . . . . . . 249
7.4.23. C-09.9 - Non-Effective Staging . . . . . . . . . . . 249
7.4.24. PART III - PROTECTED AUTHORITY STATE . . . . . . . . 250
7.4.25. C-09.10 - Protected Authority-State Record . . . . . 250
7.4.26. C-09.11 - Native Resource Permission . . . . . . . . 250
7.4.27. C-09.12 - Protected Predicate Evaluation . . . . . . 251
7.4.28. PART IV - INLINE VALIDATION-STATE COMMITMENT . . . . 251
7.4.29. C-09.13 - Protected Validation-State
Representation . . . . . . . . . . . . . . . . . . . 252
7.4.30. C-09.14 - Internal Commitment Without External
Receipt . . . . . . . . . . . . . . . . . . . . . . . 252
7.4.31. C-09.15 - Commitment Ordering . . . . . . . . . . . . 253
7.4.32. PART V - NON-PORTABLE INLINE ENABLEMENT . . . . . . . 253
7.4.33. C-09.16 - Bounded Execution-Enabling Condition . . . 253
7.4.34. C-09.17 - Non-Portable Authority . . . . . . . . . . 254
7.4.35. C-09.18 - Transaction-Local Enablement . . . . . . . 254
7.4.36. PART VI - ATOMIC CONSUMPTION AND EFFECTUATION . . . . 255
Das Expires 25 April 2027 [Page 16]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.37. C-09.19 - Atomic Authorization Consumption . . . . . 255
7.4.38. C-09.20 - Database Atomicity . . . . . . . . . . . . 255
7.4.39. C-09.21 - Native Resource Transaction Boundary . . . 256
7.4.40. C-09.22 - Atomicity Limitation . . . . . . . . . . . 256
7.4.41. PART VII - PROTECTED CACHED AUTHORIZATION . . . . . . 257
7.4.42. C-09.23 - Cached Authorization State . . . . . . . . 257
7.4.43. C-09.24 - Cache as Intermediate Authority Input . . . 257
7.4.44. C-09.25 - Cache Generation Invalidation . . . . . . . 257
7.4.45. PART VIII - TRANSACTION-LOCAL DENIAL EVIDENCE . . . . 258
7.4.46. C-09.26 - Protected Denial State . . . . . . . . . . 258
7.4.47. C-09.27 - Denial Commitment . . . . . . . . . . . . . 258
7.4.48. C-09.28 - Denial and Retry Control . . . . . . . . . 259
7.4.49. C-09.29 - Durable Denial Following Transaction
Rollback . . . . . . . . . . . . . . . . . . . . . . 259
7.4.50. PART IX - COMPLETE INLINE EXECUTION WORKFLOW . . . . 260
7.4.51. C-09.30 - Principal 25-Step Workflow . . . . . . . . 260
7.4.52. Step C9-01 - Agent operation proposal . . . . . . . . 260
7.4.53. Step C9-02 - Controlled interface reception . . . . . 260
7.4.54. Step C9-03 - Candidate Act identification . . . . . . 260
7.4.55. Step C9-04 - Non-effective staging . . . . . . . . . 260
7.4.56. Step C9-05 - Protected transaction initiation . . . . 260
7.4.57. Step C9-06 - Actual-operation reconstruction . . . . 260
7.4.58. Step C9-07 - Descriptor canonicalization . . . . . . 260
7.4.59. Step C9-08 - Authenticated context association . . . 260
7.4.60. Step C9-09 - Native permission retrieval . . . . . . 260
7.4.61. Step C9-10 - Protected authority-state acquisition . 260
7.4.62. Step C9-11 - Resource-state protection . . . . . . . 261
7.4.63. Step C9-12 - Predicate evaluation . . . . . . . . . . 261
7.4.64. Step C9-13 - Protected-state operation . . . . . . . 261
7.4.65. Step C9-14 - Validation-state construction . . . . . 261
7.4.66. Step C9-15 - Validation-state commitment . . . . . . 261
7.4.67. Step C9-16 - Inline bounded enablement . . . . . . . 261
7.4.68. Step C9-17 - Current-operation re-acquisition . . . . 261
7.4.69. Step C9-18 - Operation-binding verification . . . . . 261
7.4.70. Step C9-19 - Protected-state verification . . . . . . 261
7.4.71. Step C9-20 - Enablement verification . . . . . . . . 261
7.4.72. Step C9-21 - Atomic authorization consumption . . . . 262
7.4.73. Step C9-22 - Native resource mutation . . . . . . . . 262
7.4.74. Step C9-23 - Atomic commit . . . . . . . . . . . . . 262
7.4.75. Step C9-24 - Outcome recording . . . . . . . . . . . 262
7.4.76. Step C9-25 - Enablement invalidation . . . . . . . . 262
7.4.77. PART X - REFERENCE IMPLEMENTATION ALGORITHMS . . . . 262
7.4.78. C-09.35 - Algorithm E: Transaction-Local Denial . . . 266
7.4.79. C-09.36 - Algorithm F: Transaction Recovery . . . . . 267
7.4.80. PART XI - WORKED TECHNICAL EXAMPLES . . . . . . . . . 268
7.4.81. C-09.41 - Example E: Protected File Commit . . . . . 270
7.4.82. PART XII - FAILURE AND ADVERSARIAL SCENARIOS . . . . 271
7.4.83. C-09.43 - Representative Failure Conditions . . . . . 271
Das Expires 25 April 2027 [Page 17]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.84. F1 - Missing Protected Validation State . . . . . . . 271
7.4.85. F2 - Invalid Operation Binding . . . . . . . . . . . 271
7.4.86. F3 - Stale Policy Generation . . . . . . . . . . . . 271
7.4.87. F4 - Revoked Authority . . . . . . . . . . . . . . . 272
7.4.88. F5 - Expired Enablement . . . . . . . . . . . . . . . 272
7.4.89. F6 - Wrong Controller . . . . . . . . . . . . . . . . 272
7.4.90. F7 - Wrong Resource . . . . . . . . . . . . . . . . . 272
7.4.91. F8 - Concurrent Consumption . . . . . . . . . . . . . 272
7.4.92. F9 - Native Resource Permission Failure . . . . . . . 272
7.4.93. F10 - Cached Authorization Stale . . . . . . . . . . 272
7.4.94. F11 - Cache Scope Expansion . . . . . . . . . . . . . 273
7.4.95. F12 - Transaction Crash Before Commit . . . . . . . . 273
7.4.96. F13 - Crash After Commit . . . . . . . . . . . . . . 273
7.4.97. F14 - Validation-State Tampering . . . . . . . . . . 273
7.4.98. F15 - Denial-State Rollback . . . . . . . . . . . . . 273
7.4.99. F16 - Candidate Identity Reuse . . . . . . . . . . . 273
7.4.100. F17 - Resource Version Conflict . . . . . . . . . . 273
7.4.101. F18 - Transaction Deadlock . . . . . . . . . . . . . 274
7.4.102. F19 - Protected-State Store Unavailable . . . . . . 274
7.4.103. F20 - Authorization Failure Followed by Retry . . . 274
7.4.104. F21 - Uncontrolled Native Resource Path . . . . . . 274
7.4.105. F22 - Remote Effect Outside Atomic Boundary . . . . 274
7.4.106. F23 - Protected Counter or Quota Exhaustion . . . . 274
7.4.107. F24 - Resource Snapshot Restoration . . . . . . . . 275
7.4.108. PART XIII - IMPLEMENTATION VARIATIONS . . . . . . . 275
7.4.109. C-09.44 - Native Database Implementation . . . . . . 275
7.4.110. C-09.45 - Payment-Switch Implementation . . . . . . 275
7.4.111. C-09.49 - TEE-Assisted Implementation . . . . . . . 275
7.4.112. PART XIV - REPRESENTATIVE DATA STRUCTURES . . . . . 276
7.4.113. C-09.53 - CandidateInlineTransactionRecord . . . . . 276
7.4.114. C-09.54 - ProtectedAuthorityRecord . . . . . . . . . 276
7.4.115. C-09.55 - InlineValidationStateRecord . . . . . . . 276
7.4.116. C-09.56 - InlineEnablementRecord . . . . . . . . . . 276
7.4.117. C-09.57 - NativeResourceStateRecord . . . . . . . . 276
7.4.118. C-09.58 - ProtectedCacheRecord . . . . . . . . . . . 277
7.4.119. C-09.59 - ProtectedDenialRecord . . . . . . . . . . 277
7.4.120. C-09.60 - TransactionRecoveryRecord . . . . . . . . 277
7.4.121. PART XV - PROPOSED VERIFICATION TESTS . . . . . . . 277
7.4.122. C-09.61 - Engineering Test Matrix . . . . . . . . . 277
7.4.123. Test Condition . . . . . . . . . . . . . . . . . . . 277
7.4.124. Expected result . . . . . . . . . . . . . . . . . . 278
7.4.125. PART XVI - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 278
7.4.126. C-09.62 - Independent enforcement point(s) 9 . . . . 278
7.4.127. C-09.63 - Dependent enforcement point(s) 10 . . . . 278
7.4.128. C-09.64 - Dependent enforcement point(s) 11 . . . . 279
7.4.129. C-09.65 - Dependent enforcement point(s) 12 . . . . 279
7.4.130. C-09.66 - Dependent enforcement point(s) 13 . . . . 279
Das Expires 25 April 2027 [Page 18]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.131. C-09.67 - Dependent enforcement point(s) 14 . . . . 280
7.4.132. PART XVII - IMPLEMENTATION REQUIREMENTS . . . . . . 280
7.4.133. C-09.68 - implementer Implementation Checklist . . . 280
7.4.134. C-09.69 - Technical Effect . . . . . . . . . . . . . 281
7.4.135. C-09.70 - Technical Summary . . . . . . . . . . . . 281
7.5. Implementation Profile C-60 . . . . . . . . . . . . . . . 282
7.5.1. C-60.1 - Technical Field . . . . . . . . . . . . . . 282
7.5.2. PART I - TECHNICAL PROBLEM . . . . . . . . . . . . . 283
7.5.3. C-60.2 - Authorization Based Only on the Requested
Operation . . . . . . . . . . . . . . . . . . . . . . 284
7.5.4. C-60.3 - Cross-Object Invariant Problem . . . . . . . 284
7.5.5. C-60.4 - Trigger-Generated Effect Problem . . . . . . 285
7.5.6. C-60.5 - Concurrent Authorization Problem . . . . . . 285
7.5.7. C-60.6 - Transactional Outbox Problem . . . . . . . . 286
7.5.8. C-60.7 - Distinction From Upstream API Admission . . 286
7.5.9. PART II - CENTRAL TECHNICAL PRINCIPLE . . . . . . . . 287
7.5.10. C-60.8 - Authorization of the Resulting State . . . . 287
7.5.11. C-60.9 - Representative Authorization Predicate . . . 287
7.5.12. C-60.10 - Atomicity Boundary . . . . . . . . . . . . 287
7.5.13. C-60.11 - No Separate DAS Receipt Requirement . . . . 288
7.5.14. PART III - PRINCIPAL SYSTEM COMPONENTS . . . . . . . 288
7.5.15. C-60.12 - Agent-Associated Resource Request
Interface . . . . . . . . . . . . . . . . . . . . . . 288
7.5.16. C-60.13 - Native Resource Engine . . . . . . . . . . 289
7.5.17. C-60.14 - Transaction-State Mechanism . . . . . . . . 289
7.5.18. C-60.15 - Dependency Evaluator . . . . . . . . . . . 289
7.5.19. C-60.16 - Projected-State Generator . . . . . . . . . 290
7.5.20. C-60.17 - Invariant Evaluator . . . . . . . . . . . . 290
7.5.21. C-60.18 - Native Transaction Controller . . . . . . . 290
7.5.22. C-60.19 - Transactional Outbox Controller . . . . . . 291
7.5.23. C-60.20 - Outbox Dispatch Worker . . . . . . . . . . 291
7.5.24. C-60.21 - Concurrent Conflict Controller . . . . . . 291
7.5.25. PART IV - RESOURCE-STATE REPRESENTATION . . . . . . . 291
7.5.26. C-60.22 - Resource Object . . . . . . . . . . . . . . 291
7.5.27. C-60.23 - Resource State Record . . . . . . . . . . . 292
7.5.28. C-60.24 - Resource Version . . . . . . . . . . . . . 292
7.5.29. C-60.25 - Prospective State . . . . . . . . . . . . . 292
7.5.30. C-60.26 - Transaction Read Set . . . . . . . . . . . 293
7.5.31. C-60.27 - Transaction Write Set . . . . . . . . . . . 293
7.5.32. C-60.28 - Dependent Change Set . . . . . . . . . . . 294
7.5.33. PART V - DEPENDENCY EVALUATION . . . . . . . . . . . 294
7.5.34. C-60.29 - Applicable Resource Dependencies . . . . . 294
7.5.35. C-60.30 - Trigger Ordering . . . . . . . . . . . . . 295
7.5.36. C-60.31 - Trigger Closure . . . . . . . . . . . . . . 295
7.5.37. C-60.32 - Trigger Cycle Handling . . . . . . . . . . 296
7.5.38. C-60.33 - External Operations Inside Triggers . . . . 296
7.5.39. PART VI - PROJECTED STATE GENERATION . . . . . . . . 296
7.5.40. C-60.34 - Combined State Construction . . . . . . . . 296
Das Expires 25 April 2027 [Page 19]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.41. C-60.35 - Prospective State Isolation . . . . . . . . 297
7.5.42. C-60.36 - Projected-State Completeness . . . . . . . 297
7.5.43. C-60.37 - Resource-Scoped Projection . . . . . . . . 297
7.5.44. PART VII - RESOURCE INVARIANTS . . . . . . . . . . . 297
7.5.45. C-60.38 - Object Integrity Invariant . . . . . . . . 298
7.5.46. C-60.39 - Field Consistency Invariant . . . . . . . . 298
7.5.47. C-60.40 - Ownership Invariant . . . . . . . . . . . . 298
7.5.48. C-60.41 - Authorization Constraint . . . . . . . . . 298
7.5.49. C-60.42 - Aggregate Mutation Bound . . . . . . . . . 299
7.5.50. C-60.43 - Prohibited State-Transition Relationship . 299
7.5.51. C-60.44 - Inter-Object Relationship Invariant . . . . 299
7.5.52. PART VIII - CROSS-OBJECT MODIFICATION . . . . . . . . 300
7.5.53. C-60.45 - Multiple Resource Objects . . . . . . . . . 300
7.5.54. C-60.46 - Cross-Object Atomicity . . . . . . . . . . 300
7.5.55. C-60.47 - Example Cross-Object Ownership Change . . . 300
7.5.56. C-60.48 - Shared Aggregate Object . . . . . . . . . . 301
7.5.57. PART IX - TRANSACTIONAL OUTBOX . . . . . . . . . . . 301
7.5.58. C-60.49 - Transactional Outbox Record . . . . . . . . 301
7.5.59. C-60.50 - Outbox Creation . . . . . . . . . . . . . . 302
7.5.60. C-60.51 - Atomic Commit Relationship . . . . . . . . 302
7.5.61. C-60.52 - Rejection Behavior . . . . . . . . . . . . 303
7.5.62. C-60.53 - Post-Commit Dispatch . . . . . . . . . . . 303
7.5.63. C-60.54 - At-Least-Once Delivery . . . . . . . . . . 303
7.5.64. C-60.55 - Event Identity Constraint . . . . . . . . . 303
7.5.65. C-60.56 - Resource-Version Binding . . . . . . . . . 304
7.5.66. PART X - CONCURRENCY AND CONFLICT CONTROL . . . . . . 304
7.5.67. C-60.59 - Concurrent Operations . . . . . . . . . . . 304
7.5.68. C-60.63 - Snapshot Isolation Limitation . . . . . . . 304
7.5.69. C-60.64 - Optimistic Revalidation . . . . . . . . . . 304
7.5.70. C-60.65 - Retry Bound . . . . . . . . . . . . . . . . 305
7.5.71. PART XI - RESOURCE-NATIVE AUTHORIZATION . . . . . . . 305
7.5.72. C-60.66 - Agent Context Binding . . . . . . . . . . . 305
7.5.73. C-60.67 - Operation Authorization . . . . . . . . . . 306
7.5.74. C-60.68 - Trigger Authority . . . . . . . . . . . . . 306
7.5.75. C-60.69 - Resource Ownership Check . . . . . . . . . 306
7.5.76. PART XII - COMPLETE PRINCIPAL WORKFLOW . . . . . . . 306
7.5.77. C-60.70 - Thirty-Four-Step Transaction Workflow . . . 306
7.5.78. Step C60-01 - Resource operation receipt . . . . . . 307
7.5.79. Step C60-02 - Requesting context identification . . . 307
7.5.80. Step C60-03 - Transaction initiation . . . . . . . . 307
7.5.81. Step C60-04 - Resource snapshot acquisition . . . . . 307
7.5.82. Step C60-05 - Read-set recording . . . . . . . . . . 307
7.5.83. Step C60-06 - Primary change construction . . . . . . 307
7.5.84. Step C60-07 - Dependency discovery . . . . . . . . . 307
7.5.85. Step C60-08 - Dependent transition evaluation . . . . 307
7.5.86. Step C60-09 - Cross-object expansion . . . . . . . . 307
7.5.87. Step C60-10 - Trigger-chain evaluation . . . . . . . 307
Das Expires 25 April 2027 [Page 20]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.88. Step C60-11 - Dependency-completeness
determination . . . . . . . . . . . . . . . . . . . . 307
7.5.89. Step C60-12 - Prospective state generation . . . . . 308
7.5.90. Step C60-13 - Applicable invariant selection . . . . 308
7.5.91. Step C60-14 - Object integrity evaluation . . . . . . 308
7.5.92. Step C60-15 - Field consistency evaluation . . . . . 308
7.5.93. Step C60-16 - Cross-object invariant evaluation . . . 308
7.5.94. Step C60-17 - Aggregate invariant evaluation . . . . 308
7.5.95. Step C60-18 - Authorization-state evaluation . . . . 308
7.5.96. Step C60-19 - Invariant decision . . . . . . . . . . 308
7.5.97. Step C60-20 - Outbox effect classification . . . . . 308
7.5.98. Step C60-21 - Event identity allocation . . . . . . . 308
7.5.99. Step C60-22 - Resource-version association . . . . . 308
7.5.100. Step C60-23 - Transactional outbox insertion . . . . 309
7.5.101. Step C60-24 - Final projected-state verification . . 309
7.5.102. Step C60-25 - Concurrency validation . . . . . . . . 309
7.5.103. Step C60-26 - Conflict handling . . . . . . . . . . 309
7.5.104. Step C60-27 - Native commit decision . . . . . . . . 309
7.5.105. Step C60-28 - Atomic commit or rollback . . . . . . 309
7.5.106. Step C60-29 - Commit outcome registration . . . . . 309
7.5.107. Step C60-30 - Outbox visibility . . . . . . . . . . 309
7.5.108. Step C60-31 - Downstream event verification . . . . 309
7.5.109. Step C60-32 - Duplicate-event handling . . . . . . . 309
7.5.110. Step C60-33 - Downstream processing . . . . . . . . 309
7.5.111. Step C60-34 - Completion and reconciliation . . . . 310
7.5.112. PART XIII - REFERENCE IMPLEMENTATION ALGORITHMS . . 310
7.5.113. C-60.81 - Algorithm K: Outbox Worker Recovery . . . 317
7.5.114. PART XIV - WORKED TECHNICAL EXAMPLES . . . . . . . . 319
7.5.115. C-60.88 - Example F: Concurrent Quota Consumption . 321
7.5.116. C-60.89 - Example G: Duplicate Outbox Event . . . . 322
7.5.117. C-60.90 - Example H: Resource-Version Consistency . 322
7.5.118. C-60.91 - Example I: Protected Inventory Transfer . 322
7.5.119. C-60.92 - Example J: Trigger Dependency Cycle . . . 323
7.5.120. C-60.94 - Example L: Outbox Dispatch Failure . . . . 323
7.5.121. PART XV - FAILURE AND ADVERSARIAL CONDITIONS . . . . 324
7.5.122. C-60.95 - Representative Failure Cases . . . . . . . 324
7.5.123. F1 - Primary-Only Authorization . . . . . . . . . . 324
7.5.124. F2 - Missing Database Trigger . . . . . . . . . . . 324
7.5.125. F3 - Hidden Stored Procedure Mutation . . . . . . . 324
7.5.126. F4 - Cross-Object Ownership Violation . . . . . . . 324
7.5.127. F5 - Invalid Aggregate State . . . . . . . . . . . . 324
7.5.128. F6 - Prohibited State Transition . . . . . . . . . . 324
7.5.129. F7 - Missing Authorization Scope . . . . . . . . . . 324
7.5.130. F8 - Trigger Recursion . . . . . . . . . . . . . . . 325
7.5.131. F9 - External Side Effect Inside Transaction . . . . 325
7.5.132. F10 - Primary Commit Without Outbox . . . . . . . . 325
7.5.133. F11 - Outbox Without Primary Commit . . . . . . . . 325
7.5.134. F12 - Outbox Event Identity Collision . . . . . . . 325
Das Expires 25 April 2027 [Page 21]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.135. F13 - Duplicate Outbox Delivery . . . . . . . . . . 325
7.5.136. F14 - Resource-Version Mismatch . . . . . . . . . . 325
7.5.137. F15 - Legitimate Historical Event . . . . . . . . . 326
7.5.138. F16 - Unauthorized Downstream Effect Class . . . . . 326
7.5.139. F17 - Concurrent Write Skew . . . . . . . . . . . . 326
7.5.140. F18 - Lost Update . . . . . . . . . . . . . . . . . 326
7.5.141. F19 - Phantom Predicate Conflict . . . . . . . . . . 326
7.5.142. F20 - Stale Resource Version . . . . . . . . . . . . 326
7.5.143. F21 - Transaction Retry Reuses Old Approval . . . . 326
7.5.144. F22 - Retry Exhaustion . . . . . . . . . . . . . . . 327
7.5.145. F23 - Transaction Timeout . . . . . . . . . . . . . 327
7.5.146. F24 - Outbox Worker Crash . . . . . . . . . . . . . 327
7.5.147. F25 - Lost External Acknowledgment . . . . . . . . . 327
7.5.148. F26 - Duplicate External Payment or Message . . . . 327
7.5.149. F27 - Resource-State Rollback . . . . . . . . . . . 327
7.5.150. F28 - Unauthorized Trigger Modification . . . . . . 327
7.5.151. F29 - New Trigger Introduced . . . . . . . . . . . . 328
7.5.152. F30 - Outbox Processing Out of Order . . . . . . . . 328
7.5.153. F31 - Incomplete Distributed Transaction . . . . . . 328
7.5.154. F32 - Snapshot Isolation Insufficient . . . . . . . 328
7.5.155. F33 - Wrong Agent Context . . . . . . . . . . . . . 328
7.5.156. F34 - Outbox Payload Substitution . . . . . . . . . 328
7.5.157. F35 - Native Engine Unavailable . . . . . . . . . . 328
7.5.158. F36 - Invariant Evaluator Failure . . . . . . . . . 329
7.5.159. F37 - Atomic Commit Outcome Unknown . . . . . . . . 329
7.5.160. F38 - Compensating Action Confused With Rollback . . 329
7.5.161. PART XVI - IMPLEMENTATION VARIATIONS . . . . . . . . 329
7.5.162. C-60.96 - Relational Database Implementation . . . . 329
7.5.163. C-60.97 - Transactional Document Database . . . . . 329
7.5.164. C-60.98 - Transactional Key-Value Engine . . . . . . 329
7.5.165. C-60.99 - Enterprise Resource Management . . . . . . 330
7.5.166. C-60.103 - Multi-Agent Concurrency . . . . . . . . . 330
7.5.167. C-60.104 - Optimistic Concurrency Variation . . . . 330
7.5.168. PART XVII - REPRESENTATIVE DATA STRUCTURES . . . . . 330
7.5.169. C-60.108 - AgentResourceOperationRecord . . . . . . 330
7.5.170. C-60.109 - NativeTransactionRecord . . . . . . . . . 330
7.5.171. C-60.110 - ProspectiveResourceStateRecord . . . . . 331
7.5.172. C-60.111 - ResourceDependencyRecord . . . . . . . . 331
7.5.173. C-60.112 - ResourceInvariantRecord . . . . . . . . . 331
7.5.174. C-60.113 - CrossObjectInvariantRecord . . . . . . . 331
7.5.175. C-60.114 - TransactionalOutboxRecord . . . . . . . . 331
7.5.176. C-60.115 - ConsumerEventLedgerRecord . . . . . . . . 332
7.5.177. C-60.116 - ConcurrentConflictRecord . . . . . . . . 332
7.5.178. C-60.117 - NativeCommitOutcomeRecord . . . . . . . . 332
7.5.179. PART XVIII - ENGINEERING VERIFICATION . . . . . . . 332
7.5.180. C-60.118 - Proposed Test Matrix . . . . . . . . . . 332
7.5.181. Test Condition . . . . . . . . . . . . . . . . . . . 333
7.5.182. Expected result . . . . . . . . . . . . . . . . . . 333
Das Expires 25 April 2027 [Page 22]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.183. PART XIX - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 334
7.5.184. C-60.119 - Independent enforcement point(s) 60 . . . 334
7.5.185. C-60.120 - Dependent enforcement point(s) 61:
Cross-Object Modification . . . . . . . . . . . . . . 335
7.5.186. PART XX - implementer IMPLEMENTATION REQUIREMENTS . 336
7.5.187. C-60.123 - Implementation Checklist . . . . . . . . 336
7.5.188. C-60.124 - Technical Effect . . . . . . . . . . . . 337
7.5.189. C-60.125 - Technical Summary . . . . . . . . . . . . 338
7.6. Implementation Profile C-76 . . . . . . . . . . . . . . . 339
7.6.1. CONTINUITY . . . . . . . . . . . . . . . . . . . . . 339
7.6.2. C-76.1 - Technical Field . . . . . . . . . . . . . . 340
7.6.3. PART I - TECHNICAL PROBLEM . . . . . . . . . . . . . 340
7.6.4. C-76.2 - Software Authorization Can Precede Physical
Effectuation . . . . . . . . . . . . . . . . . . . . 340
7.6.5. C-76.3 - Pending Commands as Future Effect
Liability . . . . . . . . . . . . . . . . . . . . . . 341
7.6.6. C-76.4 - Multi-Process Budget Circumvention . . . . . 341
7.6.7. C-76.5 - Cancellation Does Not Necessarily Stop
Effectuation . . . . . . . . . . . . . . . . . . . . 341
7.6.8. C-76.6 - Reset and Snapshot Replay . . . . . . . . . 342
7.6.9. C-76.7 - Device-Level Concurrency . . . . . . . . . . 342
7.6.10. C-76.8 - Different Resource Effect Classes . . . . . 343
7.6.11. PART II - CENTRAL TECHNICAL PRINCIPLE . . . . . . . . 343
7.6.12. C-76.9 - Pre-Queue Reservation . . . . . . . . . . . 343
7.6.13. C-76.10 - Principal Accounting Invariant . . . . . . 344
7.6.14. C-76.11 - Typed Effect Dimensions . . . . . . . . . . 344
7.6.15. C-76.12 - Reservation Conservation . . . . . . . . . 345
7.6.16. C-76.13 - Command Inertness Before Admission . . . . 345
7.6.17. C-76.14 - Enforcement Without Portable Per-Command
Receipt . . . . . . . . . . . . . . . . . . . . . . . 345
7.6.18. PART III - PRINCIPAL SYSTEM COMPONENTS . . . . . . . 346
7.6.19. C-76.15 - AI-Agent Host Execution Environment . . . . 346
7.6.20. C-76.16 - Task-Context Association Mechanism . . . . 346
7.6.21. C-76.17 - Hardware-Adjacent Admission Controller . . 346
7.6.22. C-76.18 - Hardware-Protected Accounting Table . . . . 347
7.6.23. C-76.19 - Effect Quantity Estimator . . . . . . . . . 347
7.6.24. C-76.20 - Atomic Reservation Engine . . . . . . . . . 348
7.6.25. C-76.21 - Effect-Capable Queue . . . . . . . . . . . 348
7.6.26. C-76.22 - Command-Execution Controller . . . . . . . 348
7.6.27. C-76.23 - Hardware Completion Observer . . . . . . . 348
7.6.28. C-76.24 - Completion-Reconciliation Engine . . . . . 349
7.6.29. C-76.25 - Delegation-Accounting Controller . . . . . 349
7.6.30. C-76.26 - Recovery and Queue-Continuity Controller . 350
7.6.31. C-76.27 - Protected Configuration Authority . . . . . 350
7.6.32. PART IV - TRUST AND ENFORCEMENT BOUNDARIES . . . . . 350
7.6.33. C-76.28 - Host-Controller Separation . . . . . . . . 350
7.6.34. C-76.29 - Meaning of Hardware Protection . . . . . . 350
Das Expires 25 April 2027 [Page 23]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.35. C-76.30 - Host-Controlled Descriptor Risk . . . . . . 351
7.6.36. C-76.31 - Device Queue Isolation . . . . . . . . . . 351
7.6.37. C-76.32 - Multiple Physical Paths . . . . . . . . . . 352
7.6.38. PART V - TASK AND DELEGATION IDENTITY . . . . . . . . 352
7.6.39. C-76.33 - Root Task Identity . . . . . . . . . . . . 352
7.6.40. C-76.34 - Execution Context Identity . . . . . . . . 352
7.6.41. C-76.35 - Parent-Child Delegation . . . . . . . . . . 353
7.6.42. C-76.36 - Delegation Does Not Reset Exposure . . . . 353
7.6.43. C-76.37 - Shared Root-Budget Model . . . . . . . . . 353
7.6.44. C-76.38 - Sub-Budget Allocation Model . . . . . . . . 354
7.6.45. C-76.39 - Delegation Identity Substitution . . . . . 354
7.6.46. PART VI - EFFECT-QUANTITY ESTIMATION . . . . . . . . 354
7.6.47. C-76.40 - Command Effect Quantity . . . . . . . . . . 354
7.6.48. C-76.41 - Precise Versus Conservative Bounds . . . . 355
7.6.49. C-76.42 - Unbounded Command . . . . . . . . . . . . . 355
7.6.50. C-76.43 - Scatter-Gather Descriptors . . . . . . . . 355
7.6.51. C-76.44 - Device-Generated Expansion . . . . . . . . 356
7.6.52. C-76.45 - Variable Effect Cardinality . . . . . . . . 356
7.6.53. C-76.46 - Effect Boundary Definition . . . . . . . . 356
7.6.54. PART VII - HARDWARE-PROTECTED EFFECT-ACCOUNTING
TABLE . . . . . . . . . . . . . . . . . . . . . . . . 357
7.6.55. C-76.47 - Table Schema . . . . . . . . . . . . . . . 357
7.6.56. C-76.48 - Example Table . . . . . . . . . . . . . . . 357
7.6.57. Task Effect class Limit Reserved Completed
Remaining . . . . . . . . . . . . . . . . . . . . . . 357
7.6.58. C-76.49 - Per-Command Reservation Record . . . . . . 358
7.6.59. C-76.50 - Protected Counter Update . . . . . . . . . 358
7.6.60. C-76.51 - Budget Provisioning . . . . . . . . . . . . 358
7.6.61. C-76.52 - Budget Epoch . . . . . . . . . . . . . . . 359
7.6.62. C-76.53 - Budget Increase . . . . . . . . . . . . . . 359
7.6.63. C-76.54 - Budget Reduction . . . . . . . . . . . . . 359
7.6.64. PART VIII - ATOMIC ADMISSION . . . . . . . . . . . . 359
7.6.65. C-76.55 - Reservation Before Queue Visibility . . . . 359
7.6.66. C-76.56 - Admission Transaction . . . . . . . . . . . 360
7.6.67. C-76.57 - Admission Failure . . . . . . . . . . . . . 360
7.6.68. C-76.58 - Atomic Compare-and-Update . . . . . . . . . 360
7.6.69. C-76.59 - Reservation Publication Barrier . . . . . . 360
7.6.70. C-76.60 - Duplicate Submission Identity . . . . . . . 361
7.6.71. PART IX - COMPLETION ACCOUNTING . . . . . . . . . . . 361
7.6.72. C-76.61 - Full Completion . . . . . . . . . . . . . . 361
7.6.73. C-76.62 - Partial Completion . . . . . . . . . . . . 361
7.6.74. C-76.63 - Example Partial Transfer . . . . . . . . . 362
7.6.75. C-76.64 - Verified Cancellation of Remaining
Portion . . . . . . . . . . . . . . . . . . . . . . . 362
7.6.76. C-76.65 - Partial Cancellation Without Complete
Evidence . . . . . . . . . . . . . . . . . . . . . . 362
7.6.77. C-76.68 - Device Completion Semantics . . . . . . . . 363
7.6.78. PART X - COMMAND CANCELLATION . . . . . . . . . . . . 363
Das Expires 25 April 2027 [Page 24]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.79. C-76.69 - Cancellation Request State . . . . . . . . 363
7.6.80. C-76.70 - Execution Fence . . . . . . . . . . . . . . 363
7.6.81. C-76.71 - Queue Ownership . . . . . . . . . . . . . . 363
7.6.82. C-76.72 - Late Completion . . . . . . . . . . . . . . 364
7.6.83. PART XI - NETWORK, SMARTNIC, DPU, AND DMA
IMPLEMENTATIONS . . . . . . . . . . . . . . . . . . . 364
7.6.84. C-76.75 - Programmable NIC Admission . . . . . . . . 364
7.6.85. C-76.76 - SmartNIC Implementation . . . . . . . . . . 364
7.6.86. C-76.77 - DPU Implementation . . . . . . . . . . . . 364
7.6.87. C-76.78 - DMA Controller Implementation . . . . . . . 365
7.6.88. C-76.82 - Host Process Aggregation . . . . . . . . . 365
7.6.89. PART XII - HARDWARE RESET AND RECOVERY . . . . . . . 365
7.6.90. C-76.83 - Persisted Budget State . . . . . . . . . . 365
7.6.91. C-76.84 - Host Restart . . . . . . . . . . . . . . . 365
7.6.92. C-76.85 - Device Controller Reset . . . . . . . . . . 366
7.6.93. C-76.86 - VM Snapshot Restoration . . . . . . . . . . 366
7.6.94. C-76.87 - VM Migration . . . . . . . . . . . . . . . 366
7.6.95. C-76.88 - Source Device Fencing . . . . . . . . . . . 367
7.6.96. C-76.91 - Uncertain Outstanding Commands . . . . . . 367
7.6.97. C-76.92 - Recovery Accounting Reconciliation . . . . 367
7.6.98. PART XIII - COMPLETE 40-STEP WORKFLOW . . . . . . . . 368
7.6.99. C-76.93 - Principal Execution Workflow . . . . . . . 368
7.6.100. Step C76-01 - Task identity establishment . . . . . 368
7.6.101. Step C76-02 - Budget-policy retrieval . . . . . . . 368
7.6.102. Step C76-03 - Hardware budget provisioning . . . . . 368
7.6.103. Step C76-04 - Execution-context association . . . . 368
7.6.104. Step C76-05 - Delegation verification . . . . . . . 368
7.6.105. Step C76-06 - Command generation . . . . . . . . . . 368
7.6.106. Step C76-07 - Command staging . . . . . . . . . . . 368
7.6.107. Step C76-08 - Submission context authentication . . 368
7.6.108. Step C76-09 - Root budget identification . . . . . . 368
7.6.109. Step C76-10 - Effect-class classification . . . . . 368
7.6.110. Step C76-11 - Descriptor validation . . . . . . . . 369
7.6.111. Step C76-12 - Effect-bound estimation . . . . . . . 369
7.6.112. Step C76-13 - Bound adequacy verification . . . . . 369
7.6.113. Step C76-14 - Protected budget read . . . . . . . . 369
7.6.114. Step C76-15 - Capacity evaluation . . . . . . . . . 369
7.6.115. Step C76-16 - Atomic reservation . . . . . . . . . . 369
7.6.116. Step C76-17 - Reservation record commitment . . . . 369
7.6.117. Step C76-18 - Queue publication . . . . . . . . . . 369
7.6.118. Step C76-19 - Admission outcome recording . . . . . 369
7.6.119. Step C76-20 - Hardware execution . . . . . . . . . . 369
7.6.120. Step C76-21 - Effect-bound enforcement . . . . . . . 369
7.6.121. Step C76-22 - Completion observation . . . . . . . . 370
7.6.122. Step C76-23 - Partial effect quantification . . . . 370
7.6.123. Step C76-24 - Protected reconciliation . . . . . . . 370
7.6.124. Step C76-25 - Remaining reservation retention . . . 370
7.6.125. Step C76-26 - Cancellation request handling . . . . 370
Das Expires 25 April 2027 [Page 25]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.126. Step C76-27 - Execution fencing . . . . . . . . . . 370
7.6.127. Step C76-28 - Verified cancellation accounting . . . 370
7.6.128. Step C76-29 - Duplicate-event control . . . . . . . 370
7.6.129. Step C76-30 - Delegated-work aggregation . . . . . . 370
7.6.130. Step C76-31 - Host restart detection . . . . . . . . 370
7.6.131. Step C76-32 - Controller reset detection . . . . . . 370
7.6.132. Step C76-33 - Recovery epoch establishment . . . . . 370
7.6.133. Step C76-34 - Queue inventory reconstruction . . . . 371
7.6.134. Step C76-35 - Persisted state reconciliation . . . . 371
7.6.135. Step C76-36 - Alternate-path fencing . . . . . . . . 371
7.6.136. Step C76-37 - Recovery accounting commitment . . . . 371
7.6.137. Step C76-38 - Current invariant verification . . . . 371
7.6.138. Step C76-39 - Admission resumption . . . . . . . . . 371
7.6.139. Step C76-40 - Audit and continuity recording . . . . 371
7.6.140. PART XIV - REFERENCE IMPLEMENTATION ALGORITHMS . . . 371
7.6.141. C-76.94 - Algorithm A: Protected Task-Context
Resolution . . . . . . . . . . . . . . . . . . . . . 371
7.6.142. C-76.95 - Algorithm B: Effect-Quantity Estimation . 372
7.6.143. C-76.96 - Algorithm C: Atomic Hardware Queue
Admission . . . . . . . . . . . . . . . . . . . . . . 373
7.6.144. C-76.97 - Algorithm D: Protected Budget Invariant
Check . . . . . . . . . . . . . . . . . . . . . . . . 374
7.6.145. C-76.98 - Algorithm E: Partial Completion
Reconciliation . . . . . . . . . . . . . . . . . . . 374
7.6.146. C-76.99 - Algorithm F: Verified Cancellation . . . . 375
7.6.147. C-76.100 - Algorithm G: Shared Delegated Budget . . 376
7.6.148. C-76.101 - Algorithm H: Cross-Queue Atomic
Coordination . . . . . . . . . . . . . . . . . . . . 377
7.6.149. C-76.103 - Algorithm J: Host Restart Recovery . . . 379
7.6.150. C-76.104 - Algorithm K: Controller Reset Recovery . 379
7.6.151. C-76.105 - Algorithm L: VM Migration with Budget
Fencing . . . . . . . . . . . . . . . . . . . . . . . 380
7.6.152. C-76.106 - Algorithm M: Queue Failover Duplicate
Prevention . . . . . . . . . . . . . . . . . . . . . 381
7.6.153. C-76.107 - Algorithm N: Lost Completion
Acknowledgment . . . . . . . . . . . . . . . . . . . 382
7.6.154. C-76.108 - Algorithm O: Protected Budget Integrity
Audit . . . . . . . . . . . . . . . . . . . . . . . . 383
7.6.155. PART XV - WORKED TECHNICAL EXAMPLES . . . . . . . . 383
7.6.156. C-76.109 - Example A: SmartNIC Network Byte
Budget . . . . . . . . . . . . . . . . . . . . . . . 384
7.6.157. C-76.110 - Example B: Partial Network
Transmission . . . . . . . . . . . . . . . . . . . . 384
7.6.158. C-76.111 - Example C: Two Processes Sharing One
Budget . . . . . . . . . . . . . . . . . . . . . . . 384
7.6.159. C-76.112 - Example D: NIC Virtual Functions . . . . 385
7.6.160. C-76.113 - Example E: DMA Write Budget . . . . . . . 385
7.6.161. C-76.115 - Example G: Storage Partial Write . . . . 386
Das Expires 25 April 2027 [Page 26]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.162. C-76.116 - Example H: Cancellation During DMA . . . 386
7.6.163. Execution . . . . . . . . . . . . . . . . . . . . . 386
7.6.164. C-76.118 - Example J: VM Snapshot Replay . . . . . . 387
7.6.165. C-76.119 - Example K: Queue Failover . . . . . . . . 387
7.6.166. C-76.123 - Example O: Duplicate Cancellation
Acknowledgment . . . . . . . . . . . . . . . . . . . 387
7.6.167. C-76.124 - Example P: Unbounded Hardware Command . . 388
7.6.168. PART XVI - FAILURE AND ADVERSARIAL CONDITIONS . . . 388
7.6.169. C-76.125 - Representative Failure Cases . . . . . . 388
7.6.170. F1 - Queue Admission Before Reservation . . . . . . 388
7.6.171. F2 - Software-Only Counter . . . . . . . . . . . . . 388
7.6.172. F3 - Forged Task Identity . . . . . . . . . . . . . 388
7.6.173. F4 - Child Process Budget Reset . . . . . . . . . . 388
7.6.174. F5 - Alternate Queue Bypass . . . . . . . . . . . . 388
7.6.175. F6 - Concurrent Reservation Race . . . . . . . . . . 389
7.6.176. F7 - Integer Overflow . . . . . . . . . . . . . . . 389
7.6.177. F8 - Negative Accounting . . . . . . . . . . . . . . 389
7.6.178. F9 - Underestimated Command Effect . . . . . . . . . 389
7.6.179. F10 - Unbounded Command . . . . . . . . . . . . . . 389
7.6.180. F11 - Descriptor Tampering After Admission . . . . . 389
7.6.181. F12 - Scatter-Gather Expansion . . . . . . . . . . . 389
7.6.182. F13 - Accelerator-Generated Extra Effects . . . . . 390
7.6.183. F14 - Incorrect Unit Conversion . . . . . . . . . . 390
7.6.184. F15 - Wrong Completion Boundary . . . . . . . . . . 390
7.6.185. F16 - Premature Cancellation Refund . . . . . . . . 390
7.6.186. F17 - Partial Completion Ignored . . . . . . . . . . 390
7.6.187. F18 - Duplicate Completion Event . . . . . . . . . . 390
7.6.188. F19 - Duplicate Cancellation Event . . . . . . . . . 390
7.6.189. F20 - Completion-Cancellation Race . . . . . . . . . 391
7.6.190. F21 - Late Hardware Completion . . . . . . . . . . . 391
7.6.191. F22 - Canceled Queue Entry Still Executable
Elsewhere . . . . . . . . . . . . . . . . . . . . . . 391
7.6.192. F23 - Queue Publication Failure . . . . . . . . . . 391
7.6.193. F24 - Lost Admission Acknowledgment . . . . . . . . 391
7.6.194. F25 - Lost Completion Acknowledgment . . . . . . . . 391
7.6.195. F26 - Host Restart . . . . . . . . . . . . . . . . . 391
7.6.196. F27 - Device Reset . . . . . . . . . . . . . . . . . 391
7.6.197. F28 - VM Snapshot Rollback . . . . . . . . . . . . . 392
7.6.198. F29 - VM Migration Duplication . . . . . . . . . . . 392
7.6.199. F30 - Failover Queue Duplicate . . . . . . . . . . . 392
7.6.200. F31 - Stale Reservation Reuse . . . . . . . . . . . 392
7.6.201. F32 - Controller State Rollback . . . . . . . . . . 392
7.6.202. F33 - Delegation Context Substitution . . . . . . . 392
7.6.203. F34 - Cross-Process Budget Fragmentation . . . . . . 392
7.6.204. F35 - Device Virtual Function Reassignment . . . . . 393
7.6.205. F36 - Unauthorized Budget Increase . . . . . . . . . 393
7.6.206. F37 - Revocation During Execution . . . . . . . . . 393
7.6.207. F38 - Stale Budget Epoch . . . . . . . . . . . . . . 393
Das Expires 25 April 2027 [Page 27]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.208. F39 - Hardware Accounting Memory Corruption . . . . 393
7.6.209. F40 - Controller Firmware Compromise . . . . . . . . 393
7.6.210. F41 - Peer-to-Peer Device Bypass . . . . . . . . . . 393
7.6.211. F42 - Multi-Device Shared Budget Inconsistency . . . 394
7.6.212. F43 - Incomplete Recovery Inventory . . . . . . . . 394
7.6.213. F44 - Unknown Partial Completion . . . . . . . . . . 394
7.6.214. F45 - Command Replay Across Epochs . . . . . . . . . 394
7.6.215. F46 - Budget Table Counter Wraparound . . . . . . . 394
7.6.216. PART XVII - IMPLEMENTATION VARIATIONS . . . . . . . 394
7.6.217. C-76.126 - Programmable Network Interface
Controller . . . . . . . . . . . . . . . . . . . . . 394
7.6.218. C-76.127 - SmartNIC Budget Table . . . . . . . . . . 394
7.6.219. C-76.128 - DPU Admission Service . . . . . . . . . . 395
7.6.220. C-76.129 - DMA Queue Manager . . . . . . . . . . . . 395
7.6.221. C-76.134 - Multi-Queue Shared Controller . . . . . . 395
7.6.222. C-76.139 - Distributed Device Budget Allocation . . 395
7.6.223. C-76.140 - Optional DAS Finality Integration . . . . 395
7.6.224. PART XVIII - REPRESENTATIVE TECHNICAL DATA
STRUCTURES . . . . . . . . . . . . . . . . . . . . . 396
7.6.225. C-76.141 - TaskBudgetRecord . . . . . . . . . . . . 396
7.6.226. C-76.142 - HardwareCommandRecord . . . . . . . . . . 396
7.6.227. C-76.143 - TaskContextBindingRecord . . . . . . . . 396
7.6.228. C-76.144 - EffectQuantityBoundRecord . . . . . . . . 396
7.6.229. C-76.145 - ProtectedReservationRecord . . . . . . . 397
7.6.230. C-76.146 - HardwareCompletionRecord . . . . . . . . 397
7.6.231. C-76.147 - CancellationFenceRecord . . . . . . . . . 397
7.6.232. C-76.148 - DelegatedTaskAccountingRecord . . . . . . 397
7.6.233. C-76.149 - QueueRecoveryRecord . . . . . . . . . . . 397
7.6.234. C-76.150 - FailoverCommandRecord . . . . . . . . . . 398
7.6.235. C-76.151 - ProtectedAccountingAuditRecord . . . . . 398
7.6.236. PART XIX - ENGINEERING VERIFICATION TESTS . . . . . 398
7.6.237. C-76.152 - Proposed Test Matrix . . . . . . . . . . 398
7.6.238. Test Condition . . . . . . . . . . . . . . . . . . . 398
7.6.239. Expected result . . . . . . . . . . . . . . . . . . 398
7.6.240. PART XX - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 400
7.6.241. C-76.153 - Independent enforcement point(s) 76 . . . 400
7.6.242. C-76.154 - Dependent enforcement point(s) 77: Network
and DMA Queue Admission . . . . . . . . . . . . . . . 402
7.6.243. C-76.155 - Dependent enforcement point(s) 78: Partial
Execution Accounting . . . . . . . . . . . . . . . . 402
7.6.244. PART XXI - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 402
7.6.245. C-76.157 - Implementation Checklist . . . . . . . . 403
7.6.246. C-76.158 - Technical Effect . . . . . . . . . . . . 404
7.6.247. C-76.159 - Technical Summary . . . . . . . . . . . . 405
7.7. Implementation Profile C-84 . . . . . . . . . . . . . . . 406
Das Expires 25 April 2027 [Page 28]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.1. GENERATIONS, SOFTWARE ADMISSION FENCING, DEVICE-LEVEL
EFFECTUATION RESTRICTIONS, IN- FLIGHT COMMAND SETTLEMENT,
AND MIGRATION-SAFE RECOVERY . . . . . . . . . . . . . 406
7.7.2. C-84.1 - Technical Field . . . . . . . . . . . . . . 406
7.7.3. PART I - TECHNICAL PROBLEM . . . . . . . . . . . . . 407
7.7.4. C-84.2 - Detection Is Not Containment . . . . . . . . 407
7.7.5. C-84.3 - Process Termination Is Not Hardware
Settlement . . . . . . . . . . . . . . . . . . . . . 408
7.7.6. C-84.4 - Pending Network Transmission . . . . . . . . 409
7.7.7. C-84.5 - Outstanding DMA Access . . . . . . . . . . . 409
7.7.8. C-84.6 - Accelerator Command Continuation . . . . . . 410
7.7.9. C-84.7 - Multiple Hardware Access Paths . . . . . . . 410
7.7.10. C-84.8 - Race Between Detection and Restriction . . . 411
7.7.11. C-84.9 - Incomplete Containment Acknowledgment . . . 411
7.7.12. C-84.10 - Recovery Can Reintroduce Stale Authority . 411
7.7.13. PART II - CENTRAL TECHNICAL PRINCIPLE . . . . . . . . 412
7.7.14. C-84.11 - Containment Must Reach the Effectuation
Boundary . . . . . . . . . . . . . . . . . . . . . . 412
7.7.15. Containment of an AI-agent workload is not complete
merely because new software . . . . . . . . . . . . . 412
7.7.16. C-84.12 - Three Required Completion Conditions . . . 412
7.7.17. C-84.13 - Meaning of Unresolved Operation . . . . . . 413
7.7.18. C-84.14 - No Retroactive Erasure . . . . . . . . . . 413
7.7.19. C-84.15 - No Mandatory Portable Finality Artifact . . 414
7.7.20. PART III - PRINCIPAL SYSTEM COMPONENTS . . . . . . . 414
7.7.21. C-84.16 - Agent Execution Environment . . . . . . . . 414
7.7.22. C-84.17 - Runtime Observation Mechanism . . . . . . . 415
7.7.23. C-84.18 - Execution-Context Association Mechanism . . 415
7.7.24. C-84.19 - Resource-Interface Registry . . . . . . . . 415
7.7.25. C-84.20 - Containment-Decision Engine . . . . . . . . 416
7.7.26. C-84.21 - Containment-State Controller . . . . . . . 417
7.7.27. C-84.22 - Software Execution-Control Interface . . . 417
7.7.28. C-84.23 - Hardware Containment Interface . . . . . . 417
7.7.29. C-84.24 - Network Containment Controller . . . . . . 418
7.7.30. C-84.25 - DMA and Accelerator Containment
Controller . . . . . . . . . . . . . . . . . . . . . 418
7.7.31. C-84.26 - In-Flight Operation Inventory . . . . . . . 418
7.7.32. C-84.27 - Operation-Settlement Mechanism . . . . . . 419
7.7.33. C-84.28 - Containment-Completion Controller . . . . . 419
7.7.34. C-84.29 - Recovery Controller . . . . . . . . . . . . 420
7.7.35. C-84.30 - Protected Containment Registry . . . . . . 420
7.7.36. PART IV - EXECUTION-CONTEXT ATTRIBUTION . . . . . . . 421
7.7.37. C-84.31 - Stable Execution Identity . . . . . . . . . 421
7.7.38. C-84.32 - Hardware Context Mapping . . . . . . . . . 421
7.7.39. C-84.33 - Shared Device Queues . . . . . . . . . . . 422
7.7.40. C-84.34 - Delegated Processes . . . . . . . . . . . . 422
7.7.41. C-84.35 - Service-Account Indirection . . . . . . . . 422
7.7.42. C-84.36 - Attribution Failure . . . . . . . . . . . . 423
Das Expires 25 April 2027 [Page 29]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.43. PART V - SECURITY DEVIATION AND CONTAINMENT
DECISION . . . . . . . . . . . . . . . . . . . . . . 423
7.7.44. C-84.37 - Runtime Security Event . . . . . . . . . . 423
7.7.45. C-84.38 - Kernel Observation . . . . . . . . . . . . 423
7.7.46. C-84.39 - eBPF Observation . . . . . . . . . . . . . 424
7.7.47. C-84.40 - Hypervisor Observation . . . . . . . . . . 424
7.7.48. C-84.41 - Containment Condition . . . . . . . . . . . 424
7.7.49. C-84.42 - Scope of Containment . . . . . . . . . . . 425
7.7.50. PART VI - CONTAINMENT GENERATION AND STATE MACHINE . 425
7.7.51. C-84.43 - Containment Generation . . . . . . . . . . 425
7.7.52. C-84.44 - Monotonic Generation . . . . . . . . . . . 425
7.7.53. C-84.45 - Containment State Machine . . . . . . . . . 426
7.7.54. C-84.46 - Restriction Commitment . . . . . . . . . . 426
7.7.55. C-84.47 - Restriction Distribution . . . . . . . . . 426
7.7.56. C-84.48 - Receipt Versus Enforcement . . . . . . . . 427
7.7.57. C-84.49 - Restriction Race . . . . . . . . . . . . . 427
7.7.58. PART VII - SOFTWARE COMMAND ADMISSION FENCING . . . . 427
7.7.59. C-84.50 - Admission Boundary . . . . . . . . . . . . 427
7.7.60. C-84.51 - Software Restriction Rule . . . . . . . . . 428
7.7.61. C-84.52 - Protected Admission Generation . . . . . . 428
7.7.62. C-84.53 - Kernel Hook Enforcement . . . . . . . . . . 428
7.7.63. C-84.54 - Device Driver Submission Control . . . . . 429
7.7.64. C-84.55 - Hypervisor Submission Control . . . . . . . 429
7.7.65. C-84.56 - Software Fence Acknowledgment . . . . . . . 429
7.7.66. PART VIII - HARDWARE CONTAINMENT . . . . . . . . . . 429
7.7.67. C-84.57 - Hardware Restriction Scope . . . . . . . . 429
7.7.68. C-84.58 - Device Restriction Semantics . . . . . . . 430
7.7.69. C-84.59 - Hardware Restriction Acknowledgment . . . . 430
7.7.70. C-84.60 - Queue Stop Versus Queue Drain . . . . . . . 431
7.7.71. C-84.61 - Hardware Reset . . . . . . . . . . . . . . 431
7.7.72. PART IX - NETWORK TRANSMISSION . . . . . . . . . . . 431
7.7.73. CONTAINMENT . . . . . . . . . . . . . . . . . . . . . 431
7.7.74. C-84.62 - Network Effect Boundary . . . . . . . . . . 431
7.7.75. C-84.66 - Already Transmitted Packets . . . . . . . . 432
7.7.76. C-84.67 - Partial Network Completion . . . . . . . . 432
7.7.77. C-84.68 - Packet Transmission Race . . . . . . . . . 432
7.7.78. C-84.69 - Shared Network Interface . . . . . . . . . 432
7.7.79. PART X - DMA AND IOMMU CONTAINMENT . . . . . . . . . 433
7.7.80. C-84.70 - DMA Access Context . . . . . . . . . . . . 433
7.7.81. C-84.71 - Mapping Revocation . . . . . . . . . . . . 433
7.7.82. C-84.72 - Mapping Invalidation Is Not Always
Quiescence . . . . . . . . . . . . . . . . . . . . . 433
7.7.83. C-84.75 - Device Translation Cache . . . . . . . . . 434
7.7.84. C-84.76 - Unresolved DMA Access . . . . . . . . . . . 434
7.7.85. PART XI - ACCELERATOR CONTAINMENT . . . . . . . . . . 434
7.7.86. C-84.77 - Accelerator Command Context . . . . . . . . 434
7.7.87. C-84.78 - New Accelerator Submission Restriction . . 434
7.7.88. C-84.79 - Already Executing Accelerator Work . . . . 435
Das Expires 25 April 2027 [Page 30]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.89. PART XII - IN-FLIGHT OPERATION INVENTORY . . . . . . 435
7.7.90. C-84.82 - Inventory Purpose . . . . . . . . . . . . . 435
7.7.91. C-84.83 - Command State . . . . . . . . . . . . . . . 435
7.7.92. C-84.84 - Inventory Cutoff . . . . . . . . . . . . . 435
7.7.93. C-84.85 - Queue Enumeration . . . . . . . . . . . . . 436
7.7.94. C-84.86 - Inventory Completeness . . . . . . . . . . 436
7.7.95. C-84.87 - Command Identity . . . . . . . . . . . . . 436
7.7.96. PART XIII - OPERATION SETTLEMENT . . . . . . . . . . 437
7.7.97. C-84.88 - Completed Operation . . . . . . . . . . . . 437
7.7.98. C-84.89 - Verifiably Canceled Operation . . . . . . . 437
7.7.99. C-84.90 - Unresolved Operation . . . . . . . . . . . 437
7.7.100. C-84.91 - Unresolved but Fenced . . . . . . . . . . 437
7.7.101. C-84.92 - Unresolved and Still Executable . . . . . 438
7.7.102. C-84.93 - Settlement Record . . . . . . . . . . . . 438
7.7.103. C-84.94 - Settlement Race . . . . . . . . . . . . . 438
7.7.104. PART XIV - VERIFIED CONTAINMENT COMPLETION . . . . . 438
7.7.105. C-84.95 - Completion Barrier . . . . . . . . . . . . 439
7.7.106. C-84.96 - Software Restriction Evidence . . . . . . 439
7.7.107. C-84.97 - Hardware Restriction Evidence . . . . . . 439
7.7.108. C-84.98 - In-Flight Settlement Evidence . . . . . . 440
7.7.109. C-84.99 - Completion Decision . . . . . . . . . . . 440
7.7.110. C-84.100 - Unknown Hardware State . . . . . . . . . 440
7.7.111. C-84.101 - Containment Scope Report . . . . . . . . 440
7.7.112. PART XV - MIGRATION, RESTART, AND FAILOVER . . . . . 441
7.7.113. C-84.102 - Containment Across Host Restart . . . . . 441
7.7.114. C-84.103 - Checkpoint Restoration . . . . . . . . . 441
7.7.115. C-84.104 - Virtual-Machine Migration . . . . . . . . 441
7.7.116. C-84.105 - Source-Host Fencing . . . . . . . . . . . 442
7.7.117. C-84.106 - Queue Relocation . . . . . . . . . . . . 442
7.7.118. C-84.107 - Hardware Failover . . . . . . . . . . . . 442
7.7.119. C-84.108 - Device Reset Recovery . . . . . . . . . . 442
7.7.120. C-84.109 - Containment Generation Rollback . . . . . 443
7.7.121. C-84.110 - Recovery Restriction . . . . . . . . . . 443
7.7.122. PART XVI - PRINCIPAL 40-STEP . . . . . . . . . . . . 443
7.7.123. WORKFLOW . . . . . . . . . . . . . . . . . . . . . . 443
7.7.124. C-84.111 - Complete Containment Workflow . . . . . . 443
7.7.125. Step C84-01 - Agent environment initialization . . . 443
7.7.126. Step C84-02 - Device association registration . . . 443
7.7.127. Step C84-03 - Runtime observation . . . . . . . . . 443
7.7.128. Step C84-04 - Security event normalization . . . . . 444
7.7.129. Step C84-05 - Execution context attribution . . . . 444
7.7.130. Step C84-06 - Containment-condition evaluation . . . 444
7.7.131. Step C84-07 - Affected resource scope
determination . . . . . . . . . . . . . . . . . . . . 444
7.7.132. Step C84-08 - Containment generation allocation . . 444
7.7.133. Step C84-09 - Containment state commitment . . . . . 444
7.7.134. Step C84-10 - Software admission restriction
issuance . . . . . . . . . . . . . . . . . . . . . . 444
Das Expires 25 April 2027 [Page 31]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.135. Step C84-11 - Software enforcement activation . . . 444
7.7.136. Step C84-12 - Software fence acknowledgment . . . . 444
7.7.137. Step C84-13 - Hardware interface enumeration . . . . 444
7.7.138. Step C84-14 - Hardware restriction issuance . . . . 445
7.7.139. Step C84-15 - Hardware restriction application . . . 445
7.7.140. Step C84-16 - Hardware effective-state
verification . . . . . . . . . . . . . . . . . . . . 445
7.7.141. Step C84-17 - Pre-fence command inventory . . . . . 445
7.7.142. Step C84-18 - Queue ownership reconciliation . . . . 445
7.7.143. Step C84-19 - Command identity verification . . . . 445
7.7.144. Step C84-20 - Completed operation identification . . 445
7.7.145. Step C84-21 - Pending operation identification . . . 445
7.7.146. Step C84-22 - Supported cancellation evaluation . . 445
7.7.147. Step C84-23 - Network queue settlement . . . . . . . 445
7.7.148. Step C84-24 - DMA access settlement . . . . . . . . 445
7.7.149. Step C84-25 - Accelerator settlement . . . . . . . . 446
7.7.150. Step C84-26 - Partial completion reconciliation . . 446
7.7.151. Step C84-27 - Residual command capability
evaluation . . . . . . . . . . . . . . . . . . . . . 446
7.7.152. Step C84-28 - Broader restriction if required . . . 446
7.7.153. Step C84-29 - Final software verification . . . . . 446
7.7.154. Step C84-30 - Final hardware verification . . . . . 446
7.7.155. Step C84-31 - In-flight bypass verification . . . . 446
7.7.156. Step C84-32 - Containment completion decision . . . 446
7.7.157. Step C84-33 - Containment evidence commitment . . . 446
7.7.158. Step C84-34 - Restart or migration detection . . . . 446
7.7.159. Step C84-35 - Protected generation retrieval . . . . 447
7.7.160. Step C84-36 - Destination restriction application . 447
7.7.161. Step C84-37 - Outstanding operation
reconciliation . . . . . . . . . . . . . . . . . . . 447
7.7.162. Step C84-38 - Destination consistency
verification . . . . . . . . . . . . . . . . . . . . 447
7.7.163. Step C84-39 - Restricted or authorized resumption . 447
7.7.164. Step C84-40 - Recovery audit commitment . . . . . . 447
7.7.165. PART XVII - REFERENCE IMPLEMENTATION ALGORITHMS . . 447
7.7.166. C-84.112 - Algorithm A: Security Event
Attribution . . . . . . . . . . . . . . . . . . . . . 447
7.7.167. C-84.113 - Algorithm B: Containment Decision . . . . 448
7.7.168. C-84.114 - Algorithm C: Establish Protected
Containment Generation . . . . . . . . . . . . . . . 449
7.7.169. C-84.115 - Algorithm D: Software Command Admission
Fence . . . . . . . . . . . . . . . . . . . . . . . . 449
7.7.170. C-84.116 - Algorithm E: Hardware Restriction
Application . . . . . . . . . . . . . . . . . . . . . 450
7.7.171. C-84.117 - Algorithm F: In-Flight Command
Inventory . . . . . . . . . . . . . . . . . . . . . . 451
7.7.172. C-84.118 - Algorithm G: Command Settlement
Classification . . . . . . . . . . . . . . . . . . . 452
Das Expires 25 April 2027 [Page 32]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.173. C-84.119 - Algorithm H: Network Transmission
Settlement . . . . . . . . . . . . . . . . . . . . . 453
7.7.174. C-84.120 - Algorithm I: DMA and IOMMU Settlement . . 453
7.7.175. C-84.121 - Algorithm J: Accelerator Queue
Containment . . . . . . . . . . . . . . . . . . . . . 454
7.7.176. C-84.122 - Algorithm K: Final Containment Barrier . 455
7.7.177. C-84.123 - Algorithm L: Restart-Safe Recovery . . . 455
7.7.178. C-84.124 - Algorithm M: Migration and Destination
Verification . . . . . . . . . . . . . . . . . . . . 456
7.7.179. C-84.125 - Algorithm N: Stale Generation
Rejection . . . . . . . . . . . . . . . . . . . . . . 457
7.7.180. C-84.126 - Algorithm O: Containment Evidence
Reconciliation . . . . . . . . . . . . . . . . . . . 457
7.7.181. PART XVIII - WORKED TECHNICAL EXAMPLES . . . . . . . 458
7.7.182. C-84.127 - Example A: Agent Credential Exposure
Followed by NIC Containment . . . . . . . . . . . . . 458
7.7.183. C-84.128 - Example B: Process Terminated While NIC
Queue Remains Active . . . . . . . . . . . . . . . . 459
7.7.184. C-84.129 - Example C: DMA Mapping Revocation . . . . 459
7.7.185. C-84.130 - Example D: GPU Command Continues After Host
Termination . . . . . . . . . . . . . . . . . . . . . 459
7.7.186. C-84.131 - Example E: Shared NIC Queue . . . . . . . 460
7.7.187. C-84.132 - Example F: Software Restriction Succeeds,
Hardware Restriction Fails . . . . . . . . . . . . . 460
7.7.188. C-84.134 - Example H: Partial Packet Transmission . 461
7.7.189. C-84.135 - Example I: eBPF Detection Without
Enforcement . . . . . . . . . . . . . . . . . . . . . 461
7.7.190. C-84.136 - Example J: VM Snapshot Restoration . . . 461
7.7.191. C-84.137 - Example K: Migration to Another Host . . 462
7.7.192. C-84.138 - Example L: Device Failover . . . . . . . 462
7.7.193. C-84.140 - Example N: Unknown Completion and No
Effective Fence . . . . . . . . . . . . . . . . . . . 463
7.7.194. C-84.141 - Example O: Delegated Worker with Separate
Queue . . . . . . . . . . . . . . . . . . . . . . . . 463
7.7.195. C-84.142 - Example P: Network and DMA Containment
Together . . . . . . . . . . . . . . . . . . . . . . 463
7.7.196. PART XIX - FAILURE AND ADVERSARIAL CONDITIONS . . . 464
7.7.197. C-84.143 - Representative Failure Cases . . . . . . 464
7.7.198. F1 - Detection Treated as Containment . . . . . . . 464
7.7.199. F2 - Process Termination Only . . . . . . . . . . . 464
7.7.200. F3 - eBPF Telemetry Misclassified as Enforcement . . 464
7.7.201. F4 - Missing Execution-Context Attribution . . . . . 464
7.7.202. F5 - PID Reuse . . . . . . . . . . . . . . . . . . . 464
7.7.203. F6 - Delegated Worker Omitted . . . . . . . . . . . 465
7.7.204. F7 - Shared Queue Attribution Failure . . . . . . . 465
7.7.205. F8 - Software Fence Race . . . . . . . . . . . . . . 465
7.7.206. F9 - Hardware Fence Race . . . . . . . . . . . . . . 465
Das Expires 25 April 2027 [Page 33]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.207. F10 - Configuration Receipt Mistaken for
Effectiveness . . . . . . . . . . . . . . . . . . . . 465
7.7.208. F11 - Queue Stop Without Drain . . . . . . . . . . . 465
7.7.209. F12 - NIC Packet Already Transmitted . . . . . . . . 465
7.7.210. F13 - NIC Cancellation Not Confirmed . . . . . . . . 466
7.7.211. F14 - Partial Packet Transmission . . . . . . . . . 466
7.7.212. F15 - NIC Alternate Queue . . . . . . . . . . . . . 466
7.7.213. F16 - NIC Virtual Function Bypass . . . . . . . . . 466
7.7.214. F17 - DMA Mapping Revoked Without Synchronization . 466
7.7.215. F18 - Outstanding DMA Posted Write . . . . . . . . . 466
7.7.216. F19 - Device Translation Cache Stale . . . . . . . . 466
7.7.217. F20 - Accelerator Command Continues . . . . . . . . 466
7.7.218. F21 - Accelerator Reset Ambiguity . . . . . . . . . 467
7.7.219. F22 - Storage Submission Queue Continues . . . . . . 467
7.7.220. F23 - Incorrect Completion Semantics . . . . . . . . 467
7.7.221. F24 - Incomplete Command Inventory . . . . . . . . . 467
7.7.222. F25 - Duplicate Command Records . . . . . . . . . . 467
7.7.223. F26 - Lost Completion Acknowledgment . . . . . . . . 467
7.7.224. F27 - Unresolved Command Still Executable . . . . . 467
7.7.225. F28 - Unresolved Command Effectively Fenced . . . . 468
7.7.226. F29 - Cancellation-Completion Race . . . . . . . . . 468
7.7.227. F30 - Software Restriction Stale . . . . . . . . . . 468
7.7.228. F31 - Hardware Restriction Stale . . . . . . . . . . 468
7.7.229. F32 - Mixed Restriction Generations . . . . . . . . 468
7.7.230. F33 - Agent Recreates Process . . . . . . . . . . . 468
7.7.231. F34 - Agent Reopens Device Handle . . . . . . . . . 468
7.7.232. F35 - Container Restart . . . . . . . . . . . . . . 469
7.7.233. F36 - VM Snapshot Rollback . . . . . . . . . . . . . 469
7.7.234. F37 - VM Migration Without State Transfer . . . . . 469
7.7.235. F38 - Source VM Remains Active After Migration . . . 469
7.7.236. F39 - Queue Relocation . . . . . . . . . . . . . . . 469
7.7.237. F40 - Hardware Failover to Stale Standby . . . . . . 469
7.7.238. F41 - Device Reset Clears Restriction Register . . . 469
7.7.239. F42 - Protected Registry Unavailable . . . . . . . . 469
7.7.240. F43 - Containment Generation Rollback . . . . . . . 470
7.7.241. F44 - Forged Hardware Acknowledgment . . . . . . . . 470
7.7.242. F45 - Unknown Device Interface . . . . . . . . . . . 470
7.7.243. F46 - Telemetry Loss . . . . . . . . . . . . . . . . 470
7.7.244. F47 - Containment Controller Crash . . . . . . . . . 470
7.7.245. F48 - False Full-Containment Report . . . . . . . . 470
7.7.246. PART XX - IMPLEMENTATION VARIATIONS . . . . . . . . 470
7.7.247. C-84.144 - Linux Kernel and eBPF Observation . . . . 470
7.7.248. C-84.145 - Linux Security Module Enforcement . . . . 471
7.7.249. C-84.150 - IOMMU-Associated DMA Containment . . . . 471
7.7.250. C-84.151 - GPU Command-Queue Containment . . . . . . 471
7.7.251. C-84.156 - Hardware Controller Without Fine-Grained
Cancellation . . . . . . . . . . . . . . . . . . . . 471
7.7.252. C-84.157 - Optional DAS Finality Integration . . . . 472
Das Expires 25 April 2027 [Page 34]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.253. PART XXI - REPRESENTATIVE TECHNICAL DATA
STRUCTURES . . . . . . . . . . . . . . . . . . . . . 472
7.7.254. C-84.158 - SecurityEventRecord . . . . . . . . . . . 472
7.7.255. C-84.159 - ExecutionContextAssociationRecord . . . . 472
7.7.256. C-84.160 - ResourceInterfaceRecord . . . . . . . . . 472
7.7.257. C-84.161 - ContainmentStateRecord . . . . . . . . . 472
7.7.258. C-84.162 - SoftwareFenceRecord . . . . . . . . . . . 473
7.7.259. C-84.163 - HardwareFenceRecord . . . . . . . . . . . 473
7.7.260. C-84.164 - InFlightCommandRecord . . . . . . . . . . 473
7.7.261. C-84.165 - OperationSettlementRecord . . . . . . . . 473
7.7.262. C-84.166 - NetworkSettlementRecord . . . . . . . . . 473
7.7.263. C-84.167 - DMAContainmentRecord . . . . . . . . . . 474
7.7.264. C-84.168 - ContainmentCompletionRecord . . . . . . . 474
7.7.265. C-84.169 - RecoveryContinuityRecord . . . . . . . . 474
7.7.266. PART XXII - ENGINEERING VERIFICATION TESTS . . . . . 474
7.7.267. C-84.170 - Proposed Test Matrix . . . . . . . . . . 474
7.7.268. Test Condition . . . . . . . . . . . . . . . . . . . 474
7.7.269. Expected result . . . . . . . . . . . . . . . . . . 475
7.7.270. PART XXIII - Enforcement Points-TO- EMBODIMENT
SUPPORT . . . . . . . . . . . . . . . . . . . . . . . 477
7.7.271. C-84.171 - Independent enforcement point(s) 84 . . . 477
7.7.272. C-84.172 - Dependent enforcement point(s) 85: Network
Transmission Containment . . . . . . . . . . . . . . 478
7.7.273. C-84.173 - Dependent enforcement point(s) 86: DMA and
Accelerator Containment . . . . . . . . . . . . . . . 478
7.7.274. C-84.174 - Dependent enforcement point(s) 87:
Containment Across Migration and Failover . . . . . . 479
7.7.275. PART XXIV - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 479
7.7.276. C-84.175 - Implementation Checklist . . . . . . . . 479
7.7.277. C-84.176 - Technical Effect . . . . . . . . . . . . 480
7.7.278. C-84.177 - Technical Summary . . . . . . . . . . . . 481
7.7.279. EFFECTIVE ENFORCEMENT ACKNOWLEDGMENTS, STALE-
AUTHORITY FENCING, ASYNCHRONOUS OPERATION . . . . . . 482
8. Security Considerations . . . . . . . . . . . . . . . . . . . 482
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 483
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 483
11. Informative References . . . . . . . . . . . . . . . . . . . 483
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 483
1. Introduction
Autonomous AI agents may produce operations that invoke operating-
system services, hypervisor interfaces, network devices, native
resource engines, and accelerator queues. Isolation of computation
does not in itself establish authorization for each consequential
resource effect. This document examines execution-finality
enforcement across these interfaces. It is offered for technical
Das Expires 25 April 2027 [Page 35]
Internet-Draft Kernel-Hardware Execution Finality October 2026
discussion as an individual informational architecture, not as a
claim that any identified industry product implements the full model.
The document retains the implementation alternatives, procedures,
illustrative algorithms, constraints, and security tests contained in
the author-supplied technical disclosure. The technical profiles
reproduced below are source-derived and subject to technical editing;
terminology that originated in patent drafting is reformulated as
implementation guidance and enforcement points, not legal claim
coverage.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be
interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and
only when, they appear in all capitals. Requirements in the non-
normative profiles below are illustrative unless a later
interoperable protocol profile expressly designates them normative.
1.1. This Document Is Intentionally Long
This document is long by design. Its length is the result of
technical content, not repetition. The draft set contains 34
implementation profiles, of which this draft contains 7; each
specifies a distinct mechanism together with its components,
reference algorithms, worked examples, failure and adversarial cases,
verification tests, and enforcement points. A text comparison of the
profiles shows that fewer than 2 percent of their sentences recur in
any other profile, and the recurring text is limited to short
provenance notes and shared helper calls in the pseudocode.
The full text is retained for four reasons:
1. The security properties are compositional. A Finality Sink that
verifies a capability is necessary but not sufficient; prevention
also depends on path coverage, revocation convergence, protected
state, recovery behaviour, and the settlement of operations
already in flight. These conditions are specified in different
profiles, and a reader who examines one profile alone will see an
incomplete and potentially misleading picture.
2. The reference algorithms and negative tests are included so that
reviewers can judge implementability and attempt to falsify the
proposed properties, rather than having to accept a summary.
3. The failure cases define where each mechanism fails closed. A
condensed version would remove exactly the boundary conditions
that a security review needs to examine.
Das Expires 25 April 2027 [Page 36]
Internet-Draft Kernel-Hardware Execution Finality October 2026
4. The enforcement points state what each mechanism requires in a
form that can be checked against an implementation, and they
refer to the profile text for their technical basis.
Reviewers are therefore asked not to assess the proposal from an
isolated profile, enforcement point, or algorithm excerpt. The
recommended reading order is: this Introduction; the Problem
Statement (Section 3); Relevance to the IETF (Section 4); Scope and
Terminology (Section 6), which is identical in all three drafts;
Implementation Profile S-1 (S-1 in draft-das-sandbox-credential-
egress-finality (https://datatracker.ietf.org/doc/draft-das-sandbox-
credential-egress-finality/)), which establishes the baseline
execution-finality sequence; the remaining profiles of this draft and
then those of the companion drafts; and finally the Security
Considerations (Section 8). Each profile states its own problem,
components, algorithms, failure cases, and enforcement points, so the
profiles can be cross-checked against one another.
The 34 profiles are divided among the three drafts according to their
primary boundary, and each profile appears in full in exactly one
draft. The terminology, problem statement, IETF relevance, and
relationship to earlier drafts are identical in all three. Because
the security properties are compositional, the three drafts are
intended to be read together as one document; the Profile Map in the
next subsection shows where each profile is published.
1.2. Document Set and Cross-References
This document is one of three coordinated Internet-Drafts that share
identical terminology and are intended to be read together:
* Protected Execution Finality for Sandboxed AI Agents, Credential
Mediation, Process Lineage, and Network Egress (draft-das-sandbox-
credential-egress-finality): https://datatracker.ietf.org/doc/
draft-das-sandbox-credential-egress-finality/
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/) [I-D.das-sandbox-credential-egress-finality]
* Protected Execution-Finality Enforcement for Autonomous AI Agents
Across Kernel, Hypervisor, Hardware, and Native-Resource
Boundaries (draft-das-kernel-hardware-execution-finality, this
document): https://datatracker.ietf.org/doc/draft-das-kernel-
hardware-execution-finality/ (https://datatracker.ietf.org/doc/
draft-das-kernel-hardware-execution-finality/)
* Distributed Authority and Execution-Finality for Multi-Agent
Systems, Delegated Operations, and Cross-Domain Gateways (draft-
das-distributed-agent-authority-finality):
Das Expires 25 April 2027 [Page 37]
Internet-Draft Kernel-Hardware Execution Finality October 2026
https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/ (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/)
[I-D.das-distributed-agent-authority-finality]
This document (draft-das-kernel-hardware-execution-finality)
concentrates on the kernel, hypervisor, device, and native-resource
boundary: the point at which an operation becomes effective inside an
operating-system interface, a resource engine, a hardware queue, a
DMA or accelerator path, or device memory. The companion drafts
address the other boundaries; where a mechanism is primarily
motivated by a companion draft's focus, that draft's Problem
Statement and Relevance sections give the corresponding context.
The three drafts build on the architecture described in draft-das-
agent-execution-finality [I-D.das-agent-execution-finality],
available at https://datatracker.ietf.org/doc/draft-das-agent-
execution-finality/ (https://datatracker.ietf.org/doc/draft-das-
agent-execution-finality/). That draft is not part of this set but
provides the general execution-finality architecture on which the
profiles here rely. Readers unfamiliar with it are encouraged to
read it first.
1.3. Profile Map
The 34 profiles are published as follows. The Datatracker URL of
each draft is given in Section 1.2.
+=========+===================================+====================+
| Profile | Subject | Published in |
+=========+===================================+====================+
| S-1 | Virtual-machine-isolated agent | draft-das-sandbox- |
| | sandbox with protected execution | credential-egress- |
| | authority | finality |
+---------+-----------------------------------+--------------------+
| S-2 | Micro-VM-isolated execution with | draft-das-sandbox- |
| | lifecycle-bound authority and | credential-egress- |
| | asynchronous continuity | finality |
+---------+-----------------------------------+--------------------+
| S-3 | Container-isolated execution with | draft-das-sandbox- |
| | tool-dispatch control, credential | credential-egress- |
| | mediation, and egress finality | finality |
+---------+-----------------------------------+--------------------+
| S-4 | Process-isolated execution with | draft-das-sandbox- |
| | process-lineage control and | credential-egress- |
| | handle mediation | finality |
+---------+-----------------------------------+--------------------+
| S-5 | Kernel- and hypervisor-mediated | this document |
Das Expires 25 April 2027 [Page 38]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| | enforcement with non-bypassable | |
| | effectuation control | |
+---------+-----------------------------------+--------------------+
| S-6 | Cloud-hosted, API-gateway- | draft-das- |
| | mediated, and distributed | distributed-agent- |
| | execution with cross-domain | authority-finality |
| | authority binding | |
+---------+-----------------------------------+--------------------+
| S-7 | Hardware-rooted, | this document |
| | cryptographically isolated | |
| | execution with attested | |
| | validation | |
+---------+-----------------------------------+--------------------+
| S-8 | SmartNIC, DPU, GPU, and | this document |
| | accelerator sandbox with DMA | |
| | isolation, cross-device epoch | |
| | fencing, and memory sanitization | |
+---------+-----------------------------------+--------------------+
| C-09 | Inline transaction finality with | this document |
| | atomic authorization-state | |
| | transitions | |
+---------+-----------------------------------+--------------------+
| C-15 | Multi-agent influence-lineage | draft-das- |
| | governance | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-21 | Continuous sandbox execution with | draft-das-sandbox- |
| | bounded finality windows | credential-egress- |
| | | finality |
+---------+-----------------------------------+--------------------+
| C-33 | Effectuation-path completeness | draft-das-sandbox- |
| | and coverage-state commitment | credential-egress- |
| | | finality |
+---------+-----------------------------------+--------------------+
| C-42 | Process-lineage taint propagation | draft-das-sandbox- |
| | and transitive authority | credential-egress- |
| | restriction | finality |
+---------+-----------------------------------+--------------------+
| C-45 | Post-DNS-resolution network- | draft-das-sandbox- |
| | egress finality | credential-egress- |
| | | finality |
+---------+-----------------------------------+--------------------+
| C-48 | Compilation of effect-path | draft-das-sandbox- |
| | reachability restrictions | credential-egress- |
| | | finality |
+---------+-----------------------------------+--------------------+
| C-52 | Deferred-effect-aware identity | draft-das- |
| | authorization | distributed-agent- |
Das Expires 25 April 2027 [Page 39]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-56 | Transitive effect-closure | draft-das- |
| | admission for API requests | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-60 | Atomic projected-state | this document |
| | authorization in native resource | |
| | engines | |
+---------+-----------------------------------+--------------------+
| C-64 | Post-effect causal containment | draft-das- |
| | and selective remediation | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-68 | Source-separated human | draft-das- |
| | transaction reconstruction | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-72 | Cross-protocol authorization- | draft-das- |
| | semantics preservation | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-76 | Hardware-resident deferred-effect | this document |
| | budget accounting | |
+---------+-----------------------------------+--------------------+
| C-80 | Memory-class authority isolation | draft-das- |
| | for persistent agents | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-84 | Coordinated kernel and hardware | this document |
| | containment | |
+---------+-----------------------------------+--------------------+
| C-88 | Distributed authority contraction | draft-das- |
| | with convergence barriers | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-89 | Independence-verified guardian- | draft-das- |
| | agent supervision | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-90 | Observation-coverage attestation | draft-das- |
| | | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-91 | Side-effect-suppressed model | draft-das- |
| | migration | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
Das Expires 25 April 2027 [Page 40]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| C-92 | Partition-safe governance across | draft-das- |
| | disconnected domains | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-94 | Live agent-tool replacement with | draft-das- |
| | differential validation | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-95 | Cross-agent effect-collision | draft-das- |
| | detection and scheduling | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-96 | Task-preserving context | draft-das- |
| | minimization across providers | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-98 | Counterfactual policy deployment | draft-das- |
| | with canary rollout | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-99 | Selective erasure and non-revival | draft-das- |
| | of derived memory | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
Table 1
1.4. Relationship to Earlier Internet-Drafts
This subsection states what the author's earlier Internet-Drafts
disclosed and what this draft set discloses, so that reviewers can
distinguish new material from material already available.
1.4.1. What the Earlier Drafts Disclosed
draft-das-agent-execution-finality (https://datatracker.ietf.org/doc/
draft-das-agent-execution-finality/
(https://datatracker.ietf.org/doc/draft-das-agent-execution-
finality/)) describes the general architecture: mandatory
interception, Non-Effective State, the Candidate Act Descriptor, the
Protected Enforcement Domain, protected validation evidence, scoped
non-bearer capabilities, and Finality Sink verification. It applies
this architecture in a series of workflows covering sandbox egress;
network request canonicalization, destination resolution, DNS
rebinding, and redirect handling; credential brokering and surrogate-
credential substitution; privileged connectors; untrusted-input
provenance and process-lineage taint; browser and computer-use
actions; autonomous commerce; agent self-modification; multi-agent
Das Expires 25 April 2027 [Page 41]
Internet-Draft Kernel-Hardware Execution Finality October 2026
delegation; software supply-chain release; service-mesh enforcement;
model admission and the separation of model-path and effectuation-
path authorization; accelerator fabric and DMA transfers; hardware
watchdog interlocks; and confidential virtual machines and governance
VMs with SmartNIC enforcement.
Other earlier drafts specify parts of the architecture in more
detail:
* draft-das-execution-finality-protocol-layer: core vocabulary and
the invariant that computation does not itself confer authority
for consequence. https://datatracker.ietf.org/doc/draft-das-
execution-finality-protocol-layer/
(https://datatracker.ietf.org/doc/draft-das-execution-finality-
protocol-layer/)
* draft-das-execution-handle: the execution-handle objects, sink-
side verification against the reconstructed pending act, atomic
consumption, and finality receipts.
https://datatracker.ietf.org/doc/draft-das-execution-handle/
(https://datatracker.ietf.org/doc/draft-das-execution-handle/)
* draft-das-ef-registries: proposed registries for consequence
classes, sink types, decisions, and failure codes.
https://datatracker.ietf.org/doc/draft-das-ef-registries/
(https://datatracker.ietf.org/doc/draft-das-ef-registries/)
* draft-das-composite-execution-finality: joint finality across
multiple sinks. https://datatracker.ietf.org/doc/draft-das-
composite-execution-finality/ (https://datatracker.ietf.org/doc/
draft-das-composite-execution-finality/)
* draft-das-consequence-path-completeness: closing alternative paths
that bypass a sink. https://datatracker.ietf.org/doc/draft-das-
consequence-path-completeness/ (https://datatracker.ietf.org/doc/
draft-das-consequence-path-completeness/)
* draft-das-finality-bound-revocation and draft-das-state-policy-
continuity-finality: revocation and stale authorization at the
effectuation boundary. https://datatracker.ietf.org/doc/draft-das-
finality-bound-revocation/ (https://datatracker.ietf.org/doc/
draft-das-finality-bound-revocation/)
https://datatracker.ietf.org/doc/draft-das-state-policy-
continuity-finality/ (https://datatracker.ietf.org/doc/draft-das-
state-policy-continuity-finality/)
Das Expires 25 April 2027 [Page 42]
Internet-Draft Kernel-Hardware Execution Finality October 2026
* draft-das-agentic-effectuation-boundary: the threat model for
autonomous high-consequence agents.
https://datatracker.ietf.org/doc/draft-das-agentic-effectuation-
boundary/ (https://datatracker.ietf.org/doc/draft-das-agentic-
effectuation-boundary/)
* draft-das-agentic-adaptive-authorization: graduated and escalated
execution control. https://datatracker.ietf.org/doc/draft-das-
agentic-adaptive-authorization/ (https://datatracker.ietf.org/doc/
draft-das-agentic-adaptive-authorization/)
* draft-das-agentic-tool-binding: binding execution finality to AI
tool-call interfaces. https://datatracker.ietf.org/doc/draft-das-
agentic-tool-binding/ (https://datatracker.ietf.org/doc/draft-das-
agentic-tool-binding/)
* draft-das-hardware-enforced-execution-finality: hardware-enforced
execution finality. https://datatracker.ietf.org/doc/draft-das-
hardware-enforced-execution-finality/
(https://datatracker.ietf.org/doc/draft-das-hardware-enforced-
execution-finality/)
1.4.2. What This Draft Set Discloses
This draft set extends earlier mechanisms in the following ways:
* Substrate-specific sandbox profiles for virtual-machine, micro-VM,
container, process, kernel and hypervisor, cloud and API-gateway,
hardware-rooted, and SmartNIC, DPU, GPU, and accelerator
isolation, including DMA and memory isolation, cross-device epoch
fencing, and verified accelerator memory sanitization before
reassignment (S-1 in draft-das-sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/) to Section 7.3).
* Inline transaction finality using a non-portable enablement
condition held within the effectuation controller (Section 7.4).
* Multi-agent influence-lineage governance with retrieval-to-
execution separation (C-15 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/)).
* Continuous session finality with bounded windows and micro-
validation chains (C-21 in draft-das-sandbox-credential-egress-
finality (https://datatracker.ietf.org/doc/draft-das-sandbox-
credential-egress-finality/)).
Das Expires 25 April 2027 [Page 43]
Internet-Draft Kernel-Hardware Execution Finality October 2026
* An effectuation-path coverage registry with parent-sink dominance
(C-33 in draft-das-sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/)).
* Transitive process-lineage taint with descendant inheritance and
revocation generations (C-42 in draft-das-sandbox-credential-
egress-finality (https://datatracker.ietf.org/doc/draft-das-
sandbox-credential-egress-finality/)).
* Post-resolution network-egress finality with connected-endpoint
binding and alternate-route protection (C-45 in draft-das-sandbox-
credential-egress-finality (https://datatracker.ietf.org/doc/
draft-das-sandbox-credential-egress-finality/)).
It also introduces the following mechanism families, which are not
the subject of the earlier drafts listed above:
* Compilation of effect-path reachability restrictions for agent
sandboxes (C-48 in draft-das-sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/)).
* Deferred-effect-aware identity authorization (C-52 in draft-das-
distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Transitive effect-closure admission for API requests (C-56 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Atomic projected-state authorization within native resource
engines (Section 7.5).
* Post-effect causal containment and selective remediation (C-64 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Source-separated human reconstruction of agent-proposed
transactions (C-68 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/)).
Das Expires 25 April 2027 [Page 44]
Internet-Draft Kernel-Hardware Execution Finality October 2026
* Cross-protocol preservation of authorization semantics in agent
gateways (C-72 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Hardware-resident deferred-effect budget accounting (Section 7.6).
* Memory-class authority isolation for persistent agents (C-80 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Coordinated kernel and hardware containment with in-flight
operation settlement (Section 7.7).
* Distributed authority contraction with enforcement-convergence
barriers (C-88 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Independence-verified guardian-agent supervision (C-89 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Observation-coverage attestation (C-90 in draft-das-distributed-
agent-authority-finality (https://datatracker.ietf.org/doc/draft-
das-distributed-agent-authority-finality/)).
* Side-effect-suppressed model migration (C-91 in draft-das-
distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Partition-safe governance across disconnected domains (C-92 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Live tool replacement with differential validation (C-94 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Cross-agent effect-collision detection and scheduling (C-95 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
Das Expires 25 April 2027 [Page 45]
Internet-Draft Kernel-Hardware Execution Finality October 2026
* Task-preserving context minimization across model providers (C-96
in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Counterfactual policy deployment with effect-sensitive canary
rollout (C-98 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Selective erasure and non-revival of derived persistent memory
(C-99 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
This characterization is the author's. Reviewers are invited to
compare it against the earlier drafts and to report any mechanism
they consider already disclosed or incorrectly attributed.
2. IPR and Related Patent Disclosures
2.1. 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 Nos. 202631124028 and
202631125689 are separately identified as related patent-pending
applications.
2.2. Related International Patent Applications and WIPO Publications
The author identifies PCT/IB2025/058316 (WO 2025/210622); PCT/
IB2026/053385 (WO 2026/115520); PCT/IB2026/055615 (WO 2026/150382);
PCT/IB2026/055760 (WO 2026/150383); PCT/IB2026/055870 (WO
2026/150384); PCT/IB2026/056058 (WO 2026/154461); PCT/IB2026/056809
(WO 2026/172334); and PCT/IB2026/056941 (WO 2026/172336) as related
technical disclosures.
Das Expires 25 April 2027 [Page 46]
Internet-Draft Kernel-Hardware Execution Finality October 2026
2.3. Scope and Priority Qualifications
The listed applications facilitate independent examination of
original technical documents and their chronology. The presence of a
technical mechanism in this Internet-Draft does not mean it is the
subject of a pending, allowable, or granted patent claim. The scope
of patent protection, if any, depends on examination and action by
competent national or regional patent authorities and applicable law.
Entitlement to any claimed priority depends on support in the
relevant earlier application as originally filed. The chronology
does not establish that every mechanism described here was disclosed
in every earlier application. This section does not replace any
disclosure required through the IETF IPR disclosure process.
3. Problem Statement and Security Objectives
The governed operation may leave an isolated workload via file
operations, host system calls, IPC, native database or payment
engines, virtual devices, GPU output paths, DMA, accelerator queues,
or other effect-capable boundaries. A security decision made
exclusively at planning time may not bind the actual pending
operation at the later effectuation point. In-flight operations,
caching, stale versions, shared hardware, and concurrent activity
complicate containment.
3.1. General Problem
The general problem arises when an autonomous computational workload
can generate, route, delegate, store, or repeat operations that
produce consequential effects on resources it does not entirely
control. It is most significant where computation, authorization,
transmission, execution, persistence, and completion are distributed
among different software components, protection domains,
administrative authorities, or hardware devices.
In such systems an agent may propose an operation based on context
that is incomplete, stale, adversarially influenced, or outside its
authority. An authorization mechanism may approve a task or session
rather than the specific operation that eventually reaches the
resource. A connector may transform the request. An asynchronous
worker may execute after an authority change. A hardware queue may
remain active after a software containment decision. A persistent-
memory subsystem may retain information whose authorized basis has
been withdrawn. Existing authentication, authorization, and
isolation mechanisms each address part of this chain, but none of
them, on its own, establishes that the actual pending operation is
authorized at the moment it becomes effective.
Das Expires 25 April 2027 [Page 47]
Internet-Draft Kernel-Hardware Execution Finality October 2026
3.2. Specific Problems
The following problems are addressed by the profiles in this
document. Each entry states the problem, the technical requirement
it creates, and the profiles that address it.
P1 -- Computational output treated as execution authority:
An agent-generated command may be forwarded to an effect-capable
interface without independent verification of the current
operation-specific authority state, so that a model output, plan,
tool request, earlier instruction, or ordinary credential is
treated as sufficient to perform a consequential operation.
Requirement: Distinguish generation of an operation from
possession of a valid execution-enabling condition. Addressed in
S-1 in draft-das-sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/), Section 7.4.
P2 -- Insufficient binding between authorization and actual
effect:
An upstream decision may concern an intended request while the
downstream interface receives different parameters, a different
target, or an operation under a changed policy state.
Requirement: Identify the operation actually presented for
effectuation and enforce its correspondence with the authorized
representation. Addressed in Section 7.4, C-45 in draft-das-
sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/).
P3 -- Bypass through alternative effectuation paths:
An agent may reach an effect-capable resource through an intended
connector and also through a shell, browser, network, privileged
service, or recovery path; restricting one route can leave another
open. Requirement: Discover, classify, restrict, or verify every
relevant enabled effectuation path. Addressed in C-33 in draft-
das-sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/), C-48 in draft-das-sandbox-credential-egress-
finality (https://datatracker.ietf.org/doc/draft-das-sandbox-
credential-egress-finality/).
P4 -- Overbroad session and credential authority:
An agent may retain a credential or session permission after its
task, destination, scope, or risk condition changes. Requirement:
Bind credential use and operation execution to a limited current
authority state. Addressed in S-3 in draft-das-sandbox-
credential-egress-finality (https://datatracker.ietf.org/doc/
Das Expires 25 April 2027 [Page 48]
Internet-Draft Kernel-Hardware Execution Finality October 2026
draft-das-sandbox-credential-egress-finality/), C-21 in draft-das-
sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/).
P5 -- Promotion of external information into instructions:
Retrieved documents, web pages, messages, tool results, and stored
memories may contain text resembling instructions that an agent
copies, summarizes, or delegates into a proposed operation.
Requirement: Distinguish informational influence from authority-
bearing instructions. Addressed in C-15 in draft-das-distributed-
agent-authority-finality (https://datatracker.ietf.org/doc/draft-
das-distributed-agent-authority-finality/), C-42 in draft-das-
sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/), C-80 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/).
P6 -- Indirect and deferred effects escaping initial
authorization:
A permitted tool invocation may trigger downstream handlers or
delegated workers whose effects fall outside the intended scope.
Requirement: Identify and evaluate direct, indirect, and deferred
consequences while operations remain outstanding. Addressed in
C-52 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), C-56 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/).
P7 -- Inconsistent resource state under concurrent agent
operations:
Operations that are individually permissible may jointly violate
an inventory, financial, uniqueness, or other resource invariant.
Requirement: Identify shared logical resources and non-commutative
effects and coordinate execution through ordering, reservations,
or native transactions. Addressed in Section 7.5, C-95 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P8 -- Distributed revocation without confirmed enforcement:
An identity provider may reduce an agent's authority while a
gateway, connector, worker, or device controller still enforces an
earlier generation. Requirement: Determine whether restrictions
are effective across the relevant paths and prevent older
generations from enabling prohibited operations. Addressed in
Das Expires 25 April 2027 [Page 49]
Internet-Draft Kernel-Hardware Execution Finality October 2026
C-88 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), Section 7.3.
P9 -- Incomplete security observation:
Monitoring may miss events because a telemetry channel is
disabled, delayed, interrupted, or misconfigured. Requirement:
Verify the observation coverage required for each operation class
and reduce authority when coverage is insufficient. Addressed in
C-90 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P10 -- Correlated or manipulated guardian assessments:
Several guardian agents may agree only because they share a
compromised source, model output, or telemetry channel.
Requirement: Evaluate evidence-origin dependencies and protect
containment decisions from influence. Addressed in C-89 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P11 -- Software containment not settling hardware operations:
Commands already queued in network, storage, accelerator, DMA, or
peripheral interfaces may remain effect-capable after an agent is
suspended. Requirement: Coordinate software admission
restrictions with hardware fencing, command settlement, and
recovery generations. Addressed in Section 7.7, Section 7.6.
P12 -- Accelerator memory reassignment with residual state:
An accelerator memory region may retain inference state and be
reassigned before commands are quiesced or the region is
sanitized. Requirement: Verify command completion, sanitization,
mapping invalidation, and ownership generation before reuse.
Addressed in Section 7.3.
P13 -- Loss of authorization semantics in protocol translation:
Translation between agent protocols or API formats may drop a
constraint, change a default, substitute a principal, or broaden
the target. Requirement: Compare the resulting operation and
authority semantics with the originally permitted scope.
Addressed in C-72 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/).
P14 -- Unsafe model or tool migration during active tasks:
Replacing a model or tool may change the effects of unfinished
tasks or repeat completed operations. Requirement: Evaluate a
Das Expires 25 April 2027 [Page 50]
Internet-Draft Kernel-Hardware Execution Finality October 2026
candidate continuation or replacement without real external
effects and activate it only under compatible conditions.
Addressed in C-91 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/), C-94 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/).
P15 -- Excessive disclosure during cross-provider execution:
An agent may send all available enterprise context to a model
provider when only a small part is needed. Requirement: Generate
reduced-context representations that preserve task requirements
while enforcing disclosure restrictions. Addressed in C-96 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P16 -- Unsafe policy deployment and incomplete rollback:
A policy change may newly permit consequential operations, and
restoring the old policy does not reverse effects already
produced. Requirement: Evaluate counterfactual decision
differences, monitor actual effects, control promotion, and
preserve completed-operation history. Addressed in C-98 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P17 -- Revoked information remaining in derived memory:
A revoked source may continue to influence embeddings, summaries,
graphs, caches, or procedural memory. Requirement: Identify
derivation dependencies and selectively remove, regenerate,
transform, or quarantine affected representations. Addressed in
C-99 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P18 -- Revoked memory being reintroduced:
Backups, delayed jobs, stale indexes, or offline synchronization
may restore representations of prohibited source generations.
Requirement: Maintain non-revival state independently of stale
snapshots and enforce it before restoration. Addressed in C-99 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P19 -- Recovery from indeterminate operation outcomes:
A coordinator may fail after transmitting an operation but before
receiving completion evidence, and blind retry can duplicate the
Das Expires 25 April 2027 [Page 51]
Internet-Draft Kernel-Hardware Execution Finality October 2026
effect. Requirement: Distinguish completed, pending, canceled,
failed, and indeterminate outcomes using stable operation
identities and resource-side evidence. Addressed in C-21 in
draft-das-sandbox-credential-egress-finality
(https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/), C-92 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/), C-95 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/).
P20 -- Excessively broad containment or remediation:
Global restarts, full database restoration, or deletion of whole
memory collections may destroy independently authorized work.
Requirement: Identify affected contexts and dependencies so that
restriction and remediation can be applied selectively. Addressed
in C-64 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P21 -- Divergence between policy state and physical effectuation
state:
Policy databases, entitlements, resource transactions, hardware
queues, and memory indexes may hold different versions of relevant
state. Requirement: Use explicit generations, acknowledgments,
native transitions, completion watermarks, or equivalent
verification for each enforcement path. Addressed in C-88 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), Section 7.7, Section 7.3.
3.3. Primary Focus of This Draft
The problems above are addressed across the three drafts; where a
profile is published in a companion draft, the entry gives that
draft's Datatracker URL. This draft concentrates on the kernel,
hypervisor, device, and native-resource boundary: the point at which
an operation becomes effective inside an operating-system interface,
a resource engine, a hardware queue, a DMA or accelerator path, or
device memory, which corresponds principally to problems P1, P7, P11,
P12, and P21.
Das Expires 25 April 2027 [Page 52]
Internet-Draft Kernel-Hardware Execution Finality October 2026
3.4. Security Objectives
The objective is to provide machine-enforceable controls that
distinguish proposed computation from authorized resource
effectuation, identify direct and indirect consequences, maintain
current authority and consistency state, and prevent stale or
incompatible operations from becoming effective through uncontrolled
routes.
A further objective is to support continuity, migration, revocation,
recovery, and selective remediation without unnecessarily preventing
independent authorized work. Not every profile uses the same
enforcement mechanism; each profile states which objectives it
addresses and under which conditions.
4. Relevance to the IETF
4.1. Why This Is IETF Work
The problem described in this document is an interoperability
problem, not only a product-design question. A governed operation
typically passes through components built and operated by different
parties: an agent runtime, a gateway or proxy, a credential broker,
an identity provider, a resource API, and sometimes a hardware
device. Each of these components must agree on what operation is
being authorized, what evidence supports the authorization, how the
authorization is bound to that operation, and how a later change in
authority is propagated and acknowledged. Agreement of that kind
requires common objects and common verification semantics, which is
the type of problem the IETF exists to address.
The interoperable surfaces identified in this document are:
* a canonical, machine-verifiable descriptor of a pending operation,
including the rules for canonicalization and for treating unknown
or missing fields;
* the format and binding fields of a scoped, non-bearer capability
that authorizes one operation at one effectuation boundary;
* the result of Finality Sink verification, including denial reasons
that can be reported consistently;
* protected validation evidence and receipts, and how they may be
recorded or disclosed;
Das Expires 25 April 2027 [Page 53]
Internet-Draft Kernel-Hardware Execution Finality October 2026
* authority, revocation, containment, and observation-coverage
generations, and the acknowledgments that show they have taken
effect; and
* the preservation of authorization semantics when a request is
translated between agent and service protocols.
4.2. Relationship to Existing IETF Work
This document is intended to complement existing work, not to replace
it:
* OAuth 2.0 (RFC 6749), Rich Authorization Requests (RFC 9396),
Token Exchange (RFC 8693), DPoP (RFC 9449), and the OAuth Working
Group's Transaction Tokens work describe and constrain
authorization at issuance and presentation. This document
addresses the additional check at the point of effect: verifying a
capability against the operation actually presented, under current
authority state.
* GNAP (RFC 9635) provides a grant negotiation framework within
which act-bound capabilities could be expressed.
* The RATS architecture (RFC 9334) provides attestation evidence
that several profiles use as an input predicate for enforcement
substrates and device state.
* WIMSE work on workload identity is relevant to authority
propagation across services and delegated agents.
* SCITT work on transparency is relevant to the recording of
validation evidence and receipts.
* Problem Details for HTTP APIs (RFC 9457) is a candidate format for
reporting verification denials.
For this draft, the most directly relevant interfaces are attestation
of the enforcement substrate and of device state (related to RATS),
hardware and device-level authority generations, containment
signalling across queues, and verification results reported by native
resource engines.
4.3. What the Community Is Asked to Evaluate
This is not a research paper. It identifies specific objects,
interfaces, and verification steps, and it gives reference algorithms
and negative tests so that they can be checked. The author asks the
community to consider:
Das Expires 25 April 2027 [Page 54]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. whether the gap between an upstream authorization decision and
the actual effect at the effectuation boundary is recognized as
an interoperability problem;
2. which venue is appropriate for discussing it, for example
dispatch through SECDISPATCH, or one of the working groups listed
above;
3. which of the interoperable surfaces listed above, if any, would
warrant standardization first; and
4. whether the profiles, algorithms, and failure cases in this
document are technically correct, with corrections welcomed.
This document is Informational. It does not define a complete wire
protocol and requests no IANA actions.
5. Industry Alignment and Technical Relevance
Recent public developments in autonomous AI-agent security and
execution governance include Microsoft Execution Containers (MXC),
Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-
Closed Approval Protocol), and Project Perception; Google Agent
Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security
Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA
Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and
Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude
Code Auto Mode. These initiatives illustrate industry attention to
agent isolation, independent policy enforcement, action-bound
authorization, delegated authority, credential isolation, network-
egress security, hardware-assisted containment, runtime supervision,
and fail-closed controls. This draft describes related proposed
execution-finality mechanisms without asserting that these
initiatives implement them.
References to named company technologies serve only to identify
public industry context; they are not findings of implementation
equivalence, historical derivation, endorsement, or infringement.
6. Scope and Terminology
Candidate Act, Non-Effective State, Protected Enforcement Domain,
protected validation evidence, scoped finality enablement, and
Finality Sink designate logically distinct roles. Implementations
may combine roles physically where their required independence and
enforcement guarantees are retained. Certain source-described
implementation profiles are independent controls and do not require
every other architectural role.
Das Expires 25 April 2027 [Page 55]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The following 46 definitions are identical in all three drafts of
this set (draft-das-sandbox-credential-egress-finality, draft-das-
kernel-hardware-execution-finality, and draft-das-distributed-agent-
authority-finality) and apply to every profile in the set.
6.1. Technology-Neutral Architectural Definitions
Definition 1 -- Computing Environment:
In this document, a "Computing Environment" refers to one or more
physical, virtual, logical, firmware-controlled, hardware-
controlled, or distributed computing arrangements capable of
executing, processing, storing, routing, authorizing, restricting,
or effecting an operation.
A Computing Environment may comprise, without limitation, a
general-purpose processor, server, workstation, mobile device,
embedded device, cloud computing instance, virtual machine,
container, micro-virtual machine, secure enclave, trusted
execution environment, hypervisor, kernel, programmable network
interface, data-processing unit, graphics processing unit,
accelerator, storage controller, industrial controller, or
combinations thereof.
A Computing Environment may be implemented within a single
physical device or across multiple interconnected devices,
administrative domains, trust domains, or geographic locations.
The term does not require any particular operating system,
processor architecture, virtualization platform, hardware
manufacturer, or deployment model.
Definition 2 -- Isolated Execution Environment:
In this document, an "Isolated Execution Environment" refers to an
execution arrangement in which one or more operations, resources,
authority contexts, or state elements are separated from other
execution contexts by one or more enforceable isolation
mechanisms.
Isolation may be implemented using virtual machines, micro-virtual
machines, containers, operating-system namespaces, process
privilege boundaries, hypervisor controls, memory protection,
hardware enclaves, secure execution partitions, firmware
restrictions, device access controls, or combinations thereof.
The isolation mechanism may restrict access to memory, files,
devices, credentials, execution interfaces, network destinations,
system calls, persistent state, or privileged operations.
Das Expires 25 April 2027 [Page 56]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The degree and security properties of isolation depend upon the
selected implementation. An Isolated Execution Environment does
not necessarily provide cryptographic isolation unless the
applicable embodiment expressly provides such protection.
Definition 3 -- Sandbox:
In this document, a "Sandbox" refers to an execution environment
in which the operations, accessible resources, communication
paths, privileges, or external effects of one or more workloads
are constrained by an enforceable boundary.
A Sandbox may comprise a software sandbox, process sandbox,
operating-system sandbox, container, virtual machine, micro-
virtual machine, hypervisor-controlled execution context, trusted
execution environment, hardware-enforced partition, accelerator
execution partition, firmware-controlled environment, network-
restricted execution environment, or a combination thereof.
A Sandbox may be ephemeral, persistent, nested, distributed,
dynamically reconfigured, or shared among multiple cooperating
execution components subject to defined isolation and
authorization rules.
A Sandbox may restrict execution through static configuration,
dynamic policy enforcement, capability restrictions, resource-
access controls, protected authorization mechanisms, or
combinations thereof.
The term Sandbox does not, by itself, require a separate physical
machine, cryptographic enclave, human approval process, per-
operation authorization token, or particular Finality Sink
arrangement.
Definition 4 -- Protected Enforcement Domain (PED):
In this document, a "Protected Enforcement Domain" or "PED" refers
to a logical, physical, virtual, firmware-based, hardware-based,
or distributed enforcement arrangement comprising one or more
mechanisms configured to perform specified security-relevant
operations under protection against unauthorized interference by
an applicable adversarial or less-trusted execution context.
The specified operations may comprise authority-state evaluation,
policy validation, resource-access control, operation
classification, authorization-state modification, evidence
generation, scoped authorization, effect restriction, or other
enforcement operations described in a particular embodiment.
Das Expires 25 April 2027 [Page 57]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A PED may be implemented using protected operating-system
components, hypervisor services, isolated virtual machines,
trusted execution environments, secure processors, hardware
security modules, programmable network devices, firmware
controllers, protected service processes, or cooperating
components.
The protection mechanism may comprise access-control isolation,
memory isolation, privilege separation, cryptographic integrity
protection, hardware-enforced separation, authenticated inter-
component communication, or combinations thereof.
A PED may be colocated with an execution controller or
effectuation interface, provided that the required protection and
enforcement properties are maintained.
Where a particular enforcement point requires independent
validation, protected evidence commitment, or a specified
authorization-state transition, those requirements are additional
limitations and are not satisfied merely by identifying a
component as a PED.
Definition 5 -- Cryptographically Isolated Enforcement Domain
(CIED):
In this document, a "Cryptographically Isolated Enforcement
Domain" or "CIED" refers to a Protected Enforcement Domain in
which one or more specified security-critical state elements,
operations, communications, or enforcement decisions are protected
through cryptographic mechanisms providing an applicable
integrity, authenticity, confidentiality, anti-replay, or state-
continuity property.
A CIED may comprise a trusted execution environment, secure
enclave, hardware security module, protected virtual machine,
secure processor, firmware-controlled cryptographic subsystem,
cryptographically authenticated distributed enforcement service,
or a combination thereof.
Cryptographic isolation may be achieved through protected keys,
authenticated state transitions, cryptographic verification,
sealed storage, authenticated channels, hardware-rooted
measurement, or other specifically disclosed cryptographic
mechanisms.
A CIED need not be implemented within a single physical processor
where the applicable cryptographic trust and state-protection
requirements can be satisfied across cooperating components.
Das Expires 25 April 2027 [Page 58]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A CIED is not established merely by using encryption for ordinary
network transport. The applicable embodiment must identify the
security-critical material being protected, the adversary or
unauthorized modification being resisted, and the cryptographic
mechanism providing the required protection.
Definition 6 -- Finality Sink (FS):
In this document, a "Finality Sink" or "FS" refers to a logical or
physical enforcement component, interface, controller, or
protected operation boundary having effective control over whether
a specified Candidate Act is permitted to produce its designated
consequential effect.
A Finality Sink may be implemented through a network transmission
controller, API gateway, resource server, database commit
controller, file-system write interface, credential-use
controller, payment execution interface, hardware command queue,
accelerator output interface, storage controller, actuator
interface, operating-system enforcement hook, hypervisor
mechanism, or other technically controlled effectuation interface.
A Finality Sink may be located within a host, device, virtual
machine, kernel, hardware controller, external service, or
distributed execution arrangement.
Where an applicable enforcement point requires the Finality Sink
to reconstruct an actual pending operation, verify committed
validation evidence, validate a scoped capability, or update
protected sink-local state, those operations are required in
addition to the general effectuation-control function.
A monitoring-only component that lacks effective control over the
specified consequential operation is not a Finality Sink for that
operation merely because it observes the operation.
Definition 7 -- Effectuation Boundary:
In this document, an "Effectuation Boundary" refers to a
technically identifiable point or controlled transition at which
an operation is capable of producing a specified consequential
effect outside its previously non-effective, simulated, staged, or
restricted state.
An Effectuation Boundary may include a network transmission
interface, persistent storage commit, externally accepted service
invocation, credential activation, payment instruction submission,
actuator command release, hardware queue execution, publication of
information to an external recipient, or another defined resource-
state transition.
Das Expires 25 April 2027 [Page 59]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Different consequential effects of the same operation may have
different Effectuation Boundaries.
For example, admission of a command to a queue, transmission of a
network packet, acceptance by a remote service, and irreversible
modification of a remote resource may constitute distinct
effectuation events according to the effect being controlled.
The applicable embodiment shall identify which consequential
effect and boundary are governed.
Definition 8 -- Scoped Authorization Condition:
In this document, a "Scoped Authorization Condition" refers to an
authorization state, value, representation, or enforceable
predicate that permits a defined operation or class of operations
only within an applicable scope.
The condition may be represented through a cryptographic token,
protected state entry, hardware register, authorization latch,
permission-table entry, policy-evaluation result, transaction-
state predicate, bounded session entitlement, or combination
thereof.
The scope may comprise operation identity, resource identity,
principal identity, destination, permitted effect, time interval,
authority generation, usage count, risk state, or other applicable
constraints.
The term does not inherently require that the condition be
portable, bearer-based, non-bearer, cryptographically signed,
single-use, or separately issued.
Where an enforcement point expressly requires a scoped non-bearer
finality capability bound to committed validation evidence, such a
capability constitutes a more specifically constrained form of
authorization and must satisfy those additional requirements.
Definition 9 -- Protected State:
In this document, "Protected State" refers to data, control
information, configuration, or machine-maintained state whose
confidentiality, integrity, authenticity, ordering, or permitted
modification is protected against an identified unauthorized
execution context.
Das Expires 25 April 2027 [Page 60]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Protected State may comprise authority records, policy versions,
execution generations, usage counters, revocation states,
transaction states, resource ownership information, memory-
isolation metadata, hardware queue state, or authorization
conditions.
Protected State may be maintained in protected memory, secure
storage, access-controlled operating-system state, firmware,
hardware registers, authenticated databases, cryptographically
verified distributed storage, or combinations thereof.
The applicable embodiment shall specify the protected properties,
permitted state transitions, and enforcement mechanism relevant to
the governed operation.
Definition 10 -- Non-Effective State (NES):
In this document, a "Non-Effective State" or "NES" refers to a
condition in which a proposed operation has been represented,
prepared, staged, simulated, held, or otherwise processed without
yet producing the particular consequential effect whose release is
governed by the applicable embodiment.
An operation may be in a Non-Effective State relative to one
specified effect while already having produced another distinct
effect.
For example, an operation may have been recorded in a local queue
while remaining non-effective with respect to transmission to an
external service.
NES may be implemented through a transaction staging area,
execution queue, simulated resource interface, protected holding
state, deferred command buffer, restricted network interface,
uncommitted database transaction, or equivalent technical
mechanism.
Where an enforcement point requires NES to persist until a
particular validation or authorization condition is satisfied, the
corresponding embodiment shall disclose how premature effectuation
is prevented.
END OF INITIAL CORE DEFINITIONS.
6.2. General Interpretation
The following definitions apply throughout this document set unless a
particular profile or enforcement point expressly imposes a narrower
requirement.
Das Expires 25 April 2027 [Page 61]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The disclosed systems may be implemented using software, firmware,
hardware, programmable logic, microcode, dedicated circuitry,
distributed services, cloud infrastructure, embedded controllers, or
combinations thereof.
A named technical function may be implemented by one physical
component, multiple components, one software process, multiple
cooperating processes, one protected domain, or a distributed
arrangement, provided that the implementation supplies the
operational relationships and security properties required by the
applicable enforcement point.
The words hardware, software, processor, controller, module, gate,
domain, interface, and service do not by themselves impose a
particular physical partition.
References to a single component do not exclude a plurality of
cooperating components unless an enforcement point expressly requires
a single component. Conversely, references to distinct functional
roles do not necessarily require physically separate machines.
A cryptographically protected implementation is not required in every
disclosed embodiment merely because cryptographic implementations are
described. However, when an enforcement point requires cryptographic
isolation, cryptographic verification, protected-state commitment, or
hardware-rooted enforcement, the required property must be provided
by the actual implementation.
Embodiments directed to retrospective monitoring, ordinary native
authorization, predictive admission, static confinement, atomic
transaction authorization, or independent human execution need not
include the protected execution-finality sequence unless expressly
required by their corresponding enforcement points.
Descriptions of implementation alternatives do not remove a
requirement stated in an enforcement point.
6.3. Execution Environments and Sandbox Architectures
Definition 1 -- Artificial-Intelligence Agent:
An Artificial-Intelligence Agent means a software, firmware,
hardware-assisted, virtualized, distributed, or hybrid
computational system configured to select, generate, plan, modify,
schedule, delegate, or initiate one or more computational or
resource operations based at least in part on artificial-
intelligence processing.
Das Expires 25 April 2027 [Page 62]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The artificial-intelligence processing may include language-model
inference, multimodal inference, machine-learning decision
processes, learned policies, planning algorithms, model-generated
tool selection, or combinations thereof.
The agent may operate continuously, intermittently, synchronously,
asynchronously, locally, remotely, or through delegated
computational components.
An Artificial-Intelligence Agent need not independently possess
permission to complete every operation that it proposes.
Definition 2 -- Agent Execution Context:
An Agent Execution Context means a machine-identifiable collection
of execution state associated with an agent, task, process,
session, workflow, delegated operation, or group of related
computations.
The context may include an agent identifier, task identifier,
process identity, model configuration, tool configuration,
accessible resources, authority references, execution history,
memory references, policy state, outstanding operations, delegated
workers, and applicable security or administrative boundaries.
An Agent Execution Context may be represented in host memory,
protected memory, a runtime registry, virtual-machine state, a
container runtime, an identity service, a distributed execution
record, or hardware-associated command metadata.
Definition 3 -- Isolated Execution Environment:
An Isolated Execution Environment means a computational execution
environment subject to one or more technically enforced
restrictions separating at least a portion of its executable
activity, memory access, resource access, authority,
communication, or effects from another execution environment or
protected resource.
Isolation may be implemented through virtual-machine boundaries,
process isolation, operating-system namespaces, capability
restrictions, mandatory access control, hypervisor controls,
microkernel partitions, secure execution domains, hardware memory
protection, network separation, interface mediation, or
combinations thereof.
Isolation may be physical, logical, cryptographic, temporal,
administrative, or resource-specific.
Das Expires 25 April 2027 [Page 63]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The term does not imply that every listed isolation mechanism
provides equivalent security guarantees.
Definition 4 -- Virtual-Machine-Isolated Execution Environment:
A Virtual-Machine-Isolated Execution Environment means an Isolated
Execution Environment implemented at least in part through a
virtualization mechanism that presents or controls an execution
context having virtualized processor, memory, device, operating-
system, or resource interfaces.
Such an environment may comprise a conventional virtual machine,
micro-virtual machine, confidential virtual machine, hypervisor-
managed partition, hardware-assisted virtual machine, or other
execution environment providing the virtualization properties
required by the applicable embodiment.
The virtualization mechanism may employ a type-1 or type-2
hypervisor, hardware virtualization extensions, second-level
address translation, virtualized I/O devices, memory protection,
or equivalent techniques.
A container, process namespace, or user-space sandbox is not
necessarily a virtual machine merely because it supplies
isolation. Such an environment may nevertheless constitute a
Sandbox or Isolated Execution Environment under the corresponding
definitions.
A virtual machine is not automatically a PED or CIED merely
because its workloads are separated from other workloads.
Definition 5 -- Sandbox or Sandboxed Execution Environment:
A Sandbox or Sandboxed Execution Environment means an execution
environment in which access to one or more resources, authorities,
interfaces, communications, operations, or external effects is
restricted relative to a defined execution policy or enclosing
environment.
A Sandbox may be implemented using a virtual machine, micro-
virtual machine, container, process sandbox, application sandbox,
browser sandbox, WebAssembly runtime, language runtime, operating-
system security domain, system-call filter, kernel security
policy, remote execution environment, disposable execution
instance, or hardware-assisted isolation mechanism.
A Sandbox may restrict file access, process creation, memory
access, network access, credential access, device access,
privilege escalation, persistent-state modification, service
invocation, or other effects.
Das Expires 25 April 2027 [Page 64]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A Sandbox need not use a particular hypervisor, operating system,
container format, processor architecture, or vendor-specific
isolation mechanism.
The degree and type of isolation provided by the Sandbox are
properties of its implemented controls and are not established
solely by its designation as a Sandbox.
Definition 6 -- Sandbox Type or Sandbox Isolation Class:
A Sandbox Type or Sandbox Isolation Class means a machine-
identifiable classification of the technical isolation and
resource restrictions supplied by a sandboxed environment.
The classification may distinguish virtual-machine isolation,
micro-virtual-machine isolation, operating-system container
isolation, process isolation, language-runtime isolation,
application-level isolation, hardware-assisted memory isolation,
network isolation, credential isolation, and combinations thereof.
A Sandbox Isolation Class may further identify applicable
privileged-escape paths, available host interfaces, delegated
resource authority, persistence rules, and expected enforcement
mechanisms.
Where an embodiment requires an isolation property, classification
of an environment as belonging to a Sandbox Type does not
substitute for verification that the environment actually provides
the required property.
Definition 7 -- Isolation Boundary or Trust Boundary:
An Isolation Boundary or Trust Boundary means a technical
separation between execution, authority, memory, resource,
identity, or administrative contexts having different access
privileges or security assumptions.
The boundary may be enforced through hardware protection,
cryptographic verification, virtual-memory separation, hypervisor
isolation, operating-system access control, network controls,
protected API interfaces, process mediation, or combinations
thereof.
Crossing a trust boundary may involve transfer of data, invocation
of a function, delegation of authority, release of a credential,
modification of a resource, or submission of a hardware command.
An isolation boundary need not correspond to a physical machine
boundary.
Das Expires 25 April 2027 [Page 65]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Definition 8 -- Host Execution Environment or Host Domain:
A Host Execution Environment or Host Domain means an execution or
resource environment that provides, supervises, owns, or mediates
one or more capabilities or resources used by another execution
environment.
The Host Domain may comprise a host operating system, hypervisor,
privileged service, cloud control plane, resource gateway, browser
automation host, credential broker, device controller, physical
machine, or remote infrastructure service.
The Host Domain may execute on the same physical machine as a
sandbox or on a different machine.
A Host Domain is not inherently trusted merely because it is
described as a host, and its authority is determined by the
enforcement boundaries and protections actually provided.
Definition 9 -- Non-Authoritative Mediator:
A Non-Authoritative Mediator means an intermediary that proposes,
formats, observes, routes, buffers, transforms, classifies, pre-
screens, or submits an operation without independently possessing
the complete authority required to make that operation effective
under an applicable protected-finality architecture.
Examples include agent runtimes, operating-system wrappers,
container managers, user-space policy services, tool dispatchers,
network proxies, and browser automation controllers.
A mediator may enforce preliminary restrictions or deny an
operation, but where the applicable embodiment requires
independent protected finality authorization, the mediator cannot
unilaterally substitute its own approval for that required
authorization.
This definition does not prohibit an intermediary from serving as
a protected enforcement component in an implementation where it
actually satisfies the required protection and authority
conditions.
6.4. Operations, Effects, and Effectuation Boundaries
Definition 10 -- Effect-Capable Resource:
An Effect-Capable Resource means a computational, informational,
cryptographic, network, storage, financial, electronic,
electromechanical, physical, or service resource through which an
operation can produce a consequential state change, disclosure,
transmission, commitment, output, or controlled action.
Das Expires 25 April 2027 [Page 66]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Examples include files, databases, service APIs, credentials,
network interfaces, persistent memory, payment systems, message
services, accelerator queues, direct-memory-access engines,
storage controllers, display interfaces, robotic actuators, and
external devices.
A resource may be effect-capable even when it is accessed
indirectly through another service or interface.
Definition 11 -- Proposed Operation:
A Proposed Operation means an operation specified, requested,
generated, selected, scheduled, prepared, or delegated for
possible performance, whether or not it has been executed or
authorized.
The operation may be represented as an instruction, API request,
transaction descriptor, command, program invocation, tool call,
resource mutation, message, signal, queue entry, or hardware
operation descriptor.
A Proposed Operation is not necessarily a Candidate Act subject to
protected-finality processing unless the applicable profile or
enforcement point so requires.
Definition 12 -- Candidate Act:
A Candidate Act means a proposed, pending, staged, buffered,
scheduled, delegated, or otherwise identified operation having a
possible consequential effect and subject to an applicable
execution-control procedure.
A Candidate Act may comprise a software command, tool invocation,
network transmission, file mutation, storage commit, credential
operation, database transaction, memory mutation, payment
instruction, rendered output, hardware command, actuator action,
or other consequential operation.
A Candidate Act may be represented as data, code, a descriptor, a
hardware queue entry, a pending state transition, or a physical-
control instruction.
In embodiments expressly requiring protected execution finality,
the Candidate Act is maintained in a non-effective condition until
the applicable finality requirements have been satisfied.
Definition 13 -- Non-Effective State or NES:
Das Expires 25 April 2027 [Page 67]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A Non-Effective State, abbreviated NES, means a technical state in
which a governed operation may have been generated, computed,
prepared, buffered, or conditionally scheduled but has not yet
produced the consequential effect governed by the applicable
control mechanism.
NES may be implemented through a held transaction, buffered
packet, uncommitted database modification, unsubmitted tool
request, disabled execution queue, pending device command,
inaccessible output buffer, or other technically enforceable
state.
A software label indicating that an operation is pending is
insufficient where the operation can nevertheless produce the
governed effect through an uncontrolled route.
The term does not require that all internal computation be
stopped.
Definition 14 -- External Effect or Effectuation:
An External Effect means a consequential change, release,
transfer, disclosure, communication, acceptance, persistence,
operation, or observable result occurring outside the non-
effective state governed by a particular execution-control
mechanism.
The effect may be produced by software, firmware, hardware, a
remote service, a physical device, or cooperation among them.
Effectuation may include API dispatch, resource modification, data
disclosure, network transmission, credential use, database commit,
memory-state release, output rendering, physical signaling, or
actuator operation.
External does not necessarily mean outside the physical computer.
An effect may be external relative to a protected sandbox,
transaction boundary, security domain, or governed resource state.
Definition 15 -- Effectuation Path:
An Effectuation Path means a sequence of components, interfaces,
state transitions, or resource operations through which a Proposed
Operation may become consequential.
An Effectuation Path may comprise a system-call path, tool-
dispatch path, credential-use path, API path, network path, file-
system path, storage-commit path, memory-access path, accelerator
queue, firmware path, device-control path, or combination thereof.
Das Expires 25 April 2027 [Page 68]
Internet-Draft Kernel-Hardware Execution Finality October 2026
An Effectuation Path may be implemented wholly in software, wholly
in hardware, or across software-hardware boundaries.
Multiple Effectuation Paths may lead to the same consequential
resource effect.
Definition 16 -- Pre-Effectuation Boundary:
A Pre-Effectuation Boundary means a technically identifiable
control location at which a Proposed Operation may be intercepted,
restricted, modified, denied, or authorized before producing the
consequential effect governed by the applicable embodiment.
A Pre-Effectuation Boundary may be implemented at an API
dispatcher, transaction-admission interface, system-call
interceptor, operating-system security hook, proxy, storage commit
controller, device command queue, hardware access controller, or
other applicable interface.
The boundary need not be the last physical component in an
execution path, provided its controls can prevent the governed
effect as required by the particular embodiment.
Definition 17 -- Execution-Finality Boundary:
An Execution-Finality Boundary means a technical boundary at which
an operation transitions, or would transition, from a non-
effective or conditionally authorized state to a state having the
consequential effect governed by the applicable protected-finality
mechanism.
The boundary may be a software-controlled dispatch interface,
database commit point, protected network-egress path,
cryptographic signing interface, storage controller, memory
controller, hardware transmission interface, or physical actuation
interface.
The boundary may be logical or physical.
An implementation asserting non-bypassable finality must establish
that the governed effect cannot be produced through an alternative
uncontrolled path.
Definition 18 -- Finality Gate:
A Finality Gate means a technical control mechanism configured to
determine, enforce, or condition whether a Candidate Act may cross
an applicable Execution-Finality Boundary.
Das Expires 25 April 2027 [Page 69]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A Finality Gate may be implemented through protected software,
firmware, cryptographic enforcement, a trusted execution
environment, hypervisor, kernel security mechanism, protected
service, hardware controller, programmable logic, or combinations
thereof.
The Finality Gate may perform or control authorization evaluation,
protected-state handling, evidence generation, bounded enablement,
denial, or withholding as required by the applicable embodiment.
The Finality Gate is a functional role and need not constitute a
physically separate device.
Definition 19 -- Finality Sink:
A Finality Sink, abbreviated FS, means a technical component or
enforcement interface positioned at, before, or in effective non-
bypassable control of a consequential effectuation boundary, and
configured to control whether a governed Candidate Act can produce
its corresponding effect.
A Finality Sink may comprise an API dispatcher, credential-use
interface, protected gateway, network-egress controller, file-
system write controller, database commit controller, storage
controller, hypervisor-controlled execution interface, memory
controller, DMA controller, SmartNIC, DPU, accelerator interface,
cryptographic signing interface, display or rendering controller,
or physical actuator interface.
A Finality Sink may be implemented in software, firmware,
hardware, or their combination.
In protected-finality embodiments requiring scoped capability
verification, the Finality Sink verifies or is technically gated
by the applicable bounded enablement condition before
effectuation.
A software gateway constitutes a Finality Sink for a governed
effect only where its enforcement position prevents the
corresponding effect from bypassing the required verification
through another available route.
The Finality Sink and PED may be functionally distinct while
residing in the same component, provided that the required
verification relationship is implemented.
Definition 20 -- Finality Sink Verification:
Das Expires 25 April 2027 [Page 70]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Finality Sink Verification means machine-enforced validation
performed by or under control of an applicable Finality Sink to
determine whether a governed Candidate Act satisfies the finality-
enabling requirements imposed by the relevant enforcement point.
Such verification may include verification of a scoped capability,
protected-state condition, act descriptor, authorized resource
scope, protected validation-evidence reference, freshness
constraint, destination, execution boundary, or sink-local state.
The required verification elements are determined by the
applicable enforcement point and are not automatically mandatory
in every alternative authorization embodiment.
Where actual-operation correspondence is required, the Finality
Sink obtains or reconstructs sufficient properties of the pending
effectuation operation to compare it with the authorized
operation.
6.5. Protected Domains and Execution Authority
Definition 21 -- Protected Enforcement Domain or PED:
A Protected Enforcement Domain, abbreviated PED, means a computing
or enforcement domain having technically established protections
sufficient to preserve the integrity of one or more security-
critical validation, authority, state-control, or effectuation-
control operations required by the applicable embodiment.
A PED may be implemented using protected software, an operating-
system security mechanism, protected kernel service, isolated
virtual machine, hypervisor security partition, secure
microkernel, trusted execution environment, secure enclave,
hardware security module, secure element, cryptographic
coprocessor, FPGA security region, programmable network device,
SmartNIC, DPU, protected accelerator controller, secure firmware,
or cooperating protected components.
A PED may reside on the requesting device, an associated host, a
network gateway, a cloud service, a remote security processor, or
a distributed set of machines.
A PED is characterized by the protection and enforcement
properties it actually provides rather than by the product name or
location of its implementation.
Ordinary application code or an unprotected policy service is not
necessarily a PED merely because it evaluates authorization rules.
Das Expires 25 April 2027 [Page 71]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where protected-state integrity, protected validation evidence,
bounded authority, or non-bypassable enforcement is required, the
PED must supply the corresponding technical guarantees.
Definition 22 -- Cryptographically Isolated Enforcement Domain or
CIED:
A Cryptographically Isolated Enforcement Domain, abbreviated CIED,
means a PED providing cryptographically enforced separation of at
least the authority-critical functions or state specified by the
applicable embodiment.
Such separation may involve protected cryptographic keys,
authentication of validation state, integrity of executable
validation logic, sealed or authenticated mutable state, hardware-
rooted measurement, protected state recovery, or controlled
release of authority.
A CIED may be implemented using a suitable TEE, HSM, secure
enclave, secure element, protected coprocessor, cryptographically
isolated microkernel component, secure accelerator partition,
SmartNIC security domain, or a distributed cryptographically
protected enforcement arrangement.
A CIED is not established merely through encrypted communications,
possession of a TLS certificate, software code signing, or
ordinary access-control configuration unless the resulting
architecture also provides the required isolation and enforcement
properties.
Every CIED is a PED for purposes of the relevant definitions, but
a PED need not be a CIED unless the applicable enforcement point
requires cryptographic isolation.
Definition 23 -- Protected Governance Domain or PGD:
A Protected Governance Domain, abbreviated PGD, means a protected
authority domain configured to evaluate or enforce governance-
related conditions concerning identity, purpose, permitted
operations, security policy, resource scope, jurisdiction,
revocation, delegation, risk, or operational compliance.
A PGD may operate within or in cooperation with a PED or CIED.
A PGD may be implemented locally, remotely, or through a
distributed arrangement.
Das Expires 25 April 2027 [Page 72]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where a PGD performs a function required to remain protected, it
must provide the applicable state-integrity and enforcement
properties regardless of whether it is described as a policy
service, control plane, authority plane, or governance controller.
Definition 24 -- Protected Enforcement Path:
A Protected Enforcement Path means an arrangement of one or more
components through which a required security-critical operation is
performed while preserving the integrity and authority guarantees
specified by the applicable embodiment.
The path may include a PED, CIED, protected software service,
cryptographically authenticated communication channel, protected
registry, hardware controller, finality gate, or Finality Sink.
The path may span multiple machines or administrative domains.
Cryptographically authenticated communication alone does not
establish that the endpoints or intermediate authority operations
are protected.
Where an enforcement point requires a Protected Enforcement Path,
the implementation must prevent an unauthorized component from
altering or bypassing the applicable protected decision or
effectuation condition.
Definition 25 -- Protected State:
Protected State means mutable or immutable state maintained with
technical protections against unauthorized reading, modification,
substitution, rollback, replay, or other interference, to the
extent required by the applicable embodiment.
Protected State may comprise an authority record, policy epoch,
revocation generation, monotonic counter, nonce registry, quota
register, sealed transaction state, key reference, capability-
consumption entry, secure latch, protected permission bit, queue
generation, or other security-critical value.
Protected State may be stored in protected software memory, an
authenticated database, secure firmware storage, trusted execution
memory, hardware registers, an HSM, a distributed authenticated
state machine, or equivalent arrangements meeting the relevant
security requirements.
A value does not become Protected State solely because it is
logged, encrypted at rest, or labeled confidential.
Definition 26 -- Authority Predicate:
Das Expires 25 April 2027 [Page 73]
Internet-Draft Kernel-Hardware Execution Finality October 2026
An Authority Predicate means a machine-evaluable condition
contributing to a decision concerning whether an operation,
access, transaction, execution, transmission, or resource
modification is authorized.
Authority Predicates may concern identity, delegated authority,
permitted operation scope, purpose, destination, jurisdiction,
runtime behavior, resource state, policy version, revocation
state, freshness, evidence integrity, hardware security state, or
combinations thereof.
Authority Predicates may be evaluated by an ordinary authorization
controller or by a protected enforcement domain, according to the
relevant enforcement point.
No particular predicate is universally mandatory unless expressly
required by the enforcement point.
Definition 27 -- Authority Object:
An Authority Object means a machine-readable representation of one
or more permitted operations, authority constraints, scopes,
validity conditions, delegation relationships, or relevant
security-state requirements.
An Authority Object may comprise a structured policy record,
access entitlement, authorization scope object, cryptographic
authorization artifact, attested record, protected registry entry,
or equivalent structured authorization representation.
An Authority Object may be ordinary or protected, depending on the
embodiment.
An ordinary Authority Object does not automatically constitute a
scoped non-bearer finality capability.
Definition 28 -- Act Descriptor or Candidate Act Descriptor:
An Act Descriptor means a machine-readable representation
identifying sufficient properties of a proposed or pending
operation for a specified comparison, authorization, observation,
enforcement, or audit function.
Such properties may include operation identity, operation class,
requesting context, resource target, destination, arguments,
payload properties, affected state, policy version, temporal
condition, delegation context, or effectuation interface.
Das Expires 25 April 2027 [Page 74]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The descriptor may be represented by structured fields, canonical
serialization, digests, authenticated records, protected state,
hardware metadata, or combinations thereof.
Different embodiments may require different descriptor fields.
Where an enforcement point requires comparison with the actual
pending operation, a descriptor based solely on a potentially
untrusted requester's assertion may be insufficient unless the
relevant information is independently verified.
Definition 29 -- Protected Validation Evidence:
Protected Validation Evidence means a machine-verifiable
representation of a security-critical validation result whose
integrity is protected in accordance with the applicable
embodiment.
Protected Validation Evidence may comprise a signed record,
authenticated state transition, protected log entry, sealed
receipt, protected register update, cryptographic commitment,
attested result, or equivalent protected representation.
Where an enforcement point requires evidence to be committed
before or atomically with authorization of an execution-enabling
condition, the evidence must satisfy that ordering relationship.
Protected Validation Evidence is not necessarily required by
embodiments expressly directed to ordinary authorization,
retrospective monitoring, static sandbox restrictions, or other
mechanisms lacking that requirement.
Definition 30 -- Scoped Non-Bearer Capability:
A Scoped Non-Bearer Capability means a protected, bounded
technical authority condition or artifact that permits a specified
operation or class of operations to become effective only within
the validated scope and contextual constraints imposed by the
applicable protected-finality architecture.
The capability may be represented by a cryptographic authorization
object, protected key-use condition, secure register, protected
registry state, bounded permission state, secure latch, hardware
authorization entry, protected signal, or equivalent technically
enforced condition.
The capability is non-bearer in the sense that mere possession,
copying, or presentation of an ordinary credential-like
representation is insufficient to authorize arbitrary effectuation
outside the required scope and verification conditions.
Das Expires 25 April 2027 [Page 75]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where required by an enforcement point, the capability is bound to
a Candidate Act, descriptor, protected evidence, applicable
protected state, effectuation boundary, Finality Sink, freshness
condition, and permitted effectuation scope.
The term does not require a portable token, physically separate
authorization server, or external network exchange.
Definition 31 -- Bounded Enablement Condition:
A Bounded Enablement Condition means a machine-enforced condition
determining whether an operation may proceed within specified
limits.
The condition may be represented by a software-controlled
authorization state, protected registry entry, hardware
permission, latch, register, queue-admission state, credential-use
condition, or other bounded control mechanism.
In embodiments implementing a scoped non-bearer finality
capability, the Bounded Enablement Condition may be the capability
or its protected implementation form and does not necessarily
constitute an additional required component.
In alternative authorization embodiments, a bounded permission or
access state does not automatically satisfy the requirements of a
scoped non-bearer capability unless the required binding,
protection, and enforcement relationships are present.
6.6. Algorithmic and Runtime Verification
Definition 32 -- Algorithmic Intent Fingerprint or AIF:
An Algorithmic Intent Fingerprint, abbreviated AIF, means a
machine-verifiable representation of a permitted operational
intent or purpose envelope applicable to an operation or class of
operations.
The envelope may identify permitted task objectives, operation
types, destinations, resource scopes, delegation limits, temporal
conditions, or policy constraints.
AIF does not refer to a subjective psychological intention
attributed to an artificial-intelligence model.
An AIF may be compared with a proposed operation descriptor to
determine whether the operation lies within an authorized scope.
Definition 33 -- Algorithmic Logic Fingerprint or ALF:
Das Expires 25 April 2027 [Page 76]
Internet-Draft Kernel-Hardware Execution Finality October 2026
An Algorithmic Logic Fingerprint, abbreviated ALF, means a
machine-verifiable representation of computational logic,
executable workflow, model configuration, orchestration structure,
tool-selection logic, execution graph, policy configuration, or
other logic state relevant to an applicable authorization
requirement.
An ALF may be represented by a digest, canonical graph,
authenticated identifier, protected measurement, structured logic
description, or equivalent comparison artifact.
Where an enforcement point requires ALF correspondence, a runtime
logic representation is compared with a previously approved or
otherwise authorized logic condition.
AIF concerns authorized operational purpose; ALF concerns the
authorized computational logic or workflow. The two are not
interchangeable where separately required.
Definition 34 -- Runtime Behavioral Descriptor or RBD:
A Runtime Behavioral Descriptor, abbreviated RBD, means a bounded
machine-readable representation of execution behavior observed or
derived during performance of an agent task or associated
computation.
An RBD may be derived from process events, system calls, tool
invocations, network activity, memory operations, retrieval
events, resource-access patterns, execution graphs, or other
observable execution signals.
An RBD need not reveal model weights, private reasoning traces, or
complete neural activation states.
Where an enforcement point requires independently observed runtime
behavior, an agent-generated self-report alone does not satisfy
that requirement without the additional verification specified by
the enforcement point.
Definition 35 -- Machine-Verifiable:
Machine-Verifiable means capable of being evaluated by a computing
mechanism according to an identifiable test, comparison,
validation rule, mathematical relation, cryptographic
verification, state invariant, or machine-executable decision
procedure.
Machine verification may use deterministic rules, authenticated
data structures, cryptographic primitives, hardware observations,
structured measurements, or bounded computational evaluation.
Das Expires 25 April 2027 [Page 77]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The term does not require cryptographic verification in every
embodiment.
A subjective statement that an operation is safe or approved is
not machine verification without a corresponding evaluable
representation or decision procedure.
Definition 36 -- Fail-Closed Enforcement:
Fail-Closed Enforcement means an enforcement behavior in which
failure to establish one or more conditions required for
authorization causes the governed operation to be withheld,
denied, disabled, quarantined, or otherwise prevented from
producing the effect under the control of the applicable
enforcement mechanism.
Relevant failures may include unavailable validation services,
invalid authority, stale state, indeterminate verification,
replay, mismatched operation descriptors, exhausted quotas,
invalid protected state, or loss of a required enforcement
interface.
Fail-closed behavior applies to the operation and failure
conditions specified by the relevant profile or enforcement point.
A system is not necessarily globally fail-closed merely because
one interface rejects requests; the enforcement arrangement must
also account for applicable alternative effectuation routes when
non-bypassability is asserted.
# EMBODIMENT S-1
7. Source-Derived Technical Implementation Profiles
This section contains the implementation profiles whose primary
boundary is the subject of this draft: S-5, S-7, S-8, C-09, C-60,
C-76, C-84. The remaining profiles of the set are published in the
companion drafts listed in the Profile Map (Section Section 1.3).
Each profile is reproduced in full and retains the page provenance of
the original disclosure. Patent-style mapping subsections are recast
as enforcement-point mappings within their profiles. Mechanisms are
not automatically mandatory for every profile; deployment constraints
and alternatives remain applicable.
Das Expires 25 April 2027 [Page 78]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1. Implementation Profile S-5
Source location: original disclosure pages 234-278. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.1.1. S-5.1 - Technical Field
this implementation profile relates to operating-system security,
kernel-mediated execution control, hypervisor-mediated resource
protection, artificial-intelligence-agent security, protected
authorization, hardware-assisted isolation, system-call interception,
resource-access mediation, and enforcement of consequential
operations.
More particularly, the embodiment describes a computing architecture
in which one or more artificial-intelligence agents execute within an
operating-system or virtualized execution environment while security-
critical operations are intercepted, restricted, or authorized by one
or more kernel, hypervisor, firmware, hardware, or cooperating
protected enforcement components.
In representative protected-finality implementations, a proposed
consequential operation is prevented from producing its specified
effect until the applicable protected authorization conditions have
been evaluated and a Finality Sink verifies the required
authorization state for the actual pending operation.
The enforcement mechanism may be implemented using:
(a) operating-system kernel security mechanisms; (b) system-call
mediation; (c) mandatory access-control interfaces; (d) kernel
security hooks; (e) Linux Security Modules; (f) supported eBPF
enforcement mechanisms; (g) hypervisor-level interception; (h)
virtual-machine device mediation; (i) memory protection mechanisms;
(j) hardware security modules;
(k) trusted execution environments;
(l) programmable network devices;
(m) storage and input/output controllers; or
(n) combinations thereof.
Das Expires 25 April 2027 [Page 79]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The architecture is not limited to a particular operating system,
hypervisor, CPU instruction set, virtualization vendor, processor
manufacturer, or hardware security product.
7.1.2. S-5.2 - Technical Problem
An artificial-intelligence agent may execute through ordinary
processes, containers, virtual machines, generated code, tool
workers, browser automation, or delegated software services.
Such execution may ultimately produce consequential operations
through operating-system and hardware interfaces.
Examples include:
| x | System calls. |
| - | ------------------------------- |
| x | File writes. |
| x | Network transmissions. |
| x | Process creation. |
| x | Credential access. |
| x | Shared-memory modifications. |
| x | Device-control commands. |
| x | Database transactions. |
| x | Storage operations. |
| x | Accelerator command submission. |
| x | Hardware input/output. |
| x | External service invocations. |
Operating-system access controls may restrict particular operations
according to identities, security labels, resource permissions, or
kernel policies.
However, an operating-system permission does not necessarily
establish that an operation is authorized under a particular agent
task, protected resource state, transaction context, or execution-
finality requirement.
Furthermore, an operation may cross several technical boundaries
before producing its consequential effect.
For example, an agent may issue a write system call to a local
buffer, a privileged service may later read the buffer, and the
service may then transmit data to an external endpoint.
Blocking only the initial write operation may not enforce
authorization of the eventual transmission.
Das Expires 25 April 2027 [Page 80]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Conversely, allowing the initial write operation need not authorize
the subsequent external effect.
A related problem arises when kernel or hypervisor components observe
an operation but do not control the interface through which the final
consequential effect occurs.
this implementation profile addresses these distinctions by
establishing a protected relationship between the intercepted
operation, applicable authorization state, protected validation
evidence, scoped finality enablement, and the actual effectuation
boundary.
7.1.3. S-5.3 - Technical Objectives
The embodiment provides representative mechanisms for:
1. Intercepting specified operations at kernel or hypervisor
enforcement interfaces. 2. Identifying the originating agent,
workload, and execution context. 3. Distinguishing observation from
enforceable authorization control. 4. Establishing non-effective
staging for governed consequential operations. 5. Performing
protected authorization independently of untrusted agent-controlled
code. 6. Maintaining protected authority and revocation state. 7.
Committing protected validation evidence. 8. Establishing a scoped
non-bearer finality capability. 9. Verifying the actual pending
operation at a controlled Finality Sink. 10. Preventing unauthorized
effectuation through alternative kernel, device, or virtualized
interfaces. 11. Coordinating authorization with hardware and
firmware enforcement where necessary. 12. Addressing stale process
state, asynchronous execution, resource aliasing, and timeof-check/
time-of-use races. 13. Preserving required enforcement guarantees
during policy updates, restart, suspension, migration, and recovery.
14. Supporting kernel-only, hypervisor-assisted, hardware-backed,
and distributed enforcement arrangements.
The exact mechanisms required in any implementation depend upon the
applicable enforcement points and the selected consequential effects.
7.1.4. PART I - PRINCIPAL SYSTEM ARCHITECTURE
7.1.5. S-5.4 - Principal Components
A representative system comprises the following functional
components.
Das Expires 25 April 2027 [Page 81]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.6. Component A - Computing Platform
A computing device including one or more processors, memory
resources, storage interfaces, device controllers, and communication
interfaces.
The platform may comprise a physical server, workstation, cloud
computing node, edge computer, mobile device, embedded platform, or
cyber-physical controller.
7.1.7. Component B - Operating-System Kernel
A privileged software component responsible for managing processes,
memory, input/output, resource access, and selected security
decisions.
7.1.8. Component C - Optional Hypervisor
A virtualization component configured to supervise guest execution,
virtual processors, memory mappings, virtual devices, or selected
privileged operations.
7.1.9. Component D - Artificial-Intelligence-Agent Execution Context
A process, group of processes, container, virtual machine, delegated
worker, generated executable, model runtime, or other computational
workload operating under an agentassociated task context.
7.1.10. Component E - Kernel Enforcement Interface
An operating-system enforcement point configured to inspect,
restrict, deny, redirect, or otherwise control a specified class of
operations.
7.1.11. Component F - Hypervisor Enforcement Interface
A virtualization-level enforcement component capable of controlling
specified guest operations, virtual devices, memory accesses, or
privileged execution transitions.
7.1.12. Component G - Execution-Context Attribution Controller
A mechanism configured to associate operations with authenticated
agent, workload, process, virtual-machine, delegation, or task
contexts.
Das Expires 25 April 2027 [Page 82]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.13. Component H - Candidate Act Interceptor
A component configured to identify a consequential operation subject
to the applicable protected-finality procedure.
7.1.14. Component I - Non-Effective Operation Holder
A staging mechanism configured to withhold the specified
consequential effect while the required authorization procedure is
performed.
7.1.15. Component J - Protected Enforcement Domain
A PED configured to evaluate the required authority predicates and
maintain or access protected authorization state.
7.1.16. Component K - Protected Validation Evidence Controller
A mechanism configured to generate or commit the validation evidence
required by the applicable enforcement point.
7.1.17. Component L - Scoped Finality Enablement Controller
A protected mechanism configured to establish bounded non-bearer
finality authority for the validated operation.
7.1.18. Component M - Finality Sink
An enforcement component having effective control over the specified
consequential operation.
7.1.19. Component N - Protected State Registry
A registry configured to maintain authority generations, revocation
states, operation identities, authorization references, and
applicable consumption states.
7.1.20. Component O - Effectuation-Path Coverage Controller
A mechanism configured to identify and restrict alternative paths
capable of producing the same governed effect without the required
authorization.
7.1.21. Component P - Operation Recovery Controller
A component configured to maintain or reconcile operation state
during crashes, concurrent execution, asynchronous dispatch, device
failure, or authority revocation.
Das Expires 25 April 2027 [Page 83]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The listed roles may be implemented by one component, multiple
protected components, or cooperating software and hardware elements
when the applicable enforcement point permits such arrangements.
7.1.22. S-5.5 - Representative Kernel-Mediated Architecture
In one implementation, an artificial-intelligence agent operates as
an ordinary user-space process.
The agent generates a consequential operation, such as a request to
modify a protected file or transmit data through a controlled network
interface.
A kernel-mediated enforcement interface intercepts the operation.
The system obtains the authenticated execution context and determines
whether the requested operation requires protected finality.
If protected finality is required, the system prevents the operation
from producing the governed effect and constructs a Candidate Act
Descriptor.
The PED evaluates the applicable authorization predicates.
Following successful validation, protected evidence is committed and
bounded finality enablement is established.
The Finality Sink verifies the actual operation and required
authorization before permitting effectuation.
The Finality Sink may reside within a kernel-controlled interface,
host-side service, protected device driver, hypervisor backend,
dedicated security processor, or controlled hardware resource.
7.1.23. PART II - KERNEL ENFORCEMENT
7.1.24. S-5.6 - Kernel Enforcement Boundary
A Kernel Enforcement Boundary means an operating-system-controlled
interface or operation transition at which the kernel can enforce a
restriction on a specified operation before the governed consequence
occurs.
Such a boundary may include:
(a) an access-control decision associated with opening a file;
(b) a permission decision associated with a resource object;
Das Expires 25 April 2027 [Page 84]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(c) a controlled network operation;
(d) a process-execution permission decision;
(e) a protected credential-use interface;
(f) an applicable memory-management operation;
(g) a supported device-access restriction; or
(h) another enforceable kernel-mediated resource operation.
The boundary is defined by the effect it controls rather than merely
by the existence of a hook or instrumentation point.
A kernel hook that observes a network connection attempt does not
necessarily control every subsequent application message sent through
an established connection.
Similarly, permission to open a file does not necessarily amount to
independent authorization of every future modification performed
through an existing descriptor.
7.1.25. S-5.7 - System-Call Mediation
The system may identify consequential operations through selected
system-call interfaces.
Examples include system calls relating to:
| x | File access. |
| - | --------------------------- |
| x | File modification. |
| x | Network connection. |
| x | Network transmission. |
| x | Process creation. |
| x | Privilege modification. |
| x | Device control. |
| x | Memory mapping. |
| x | Interprocess communication. |
| x | Resource configuration. |
A system-call mediation mechanism may deny an operation, restrict
permitted parameters, require use of a protected broker, or impose a
supported authorization decision.
Das Expires 25 April 2027 [Page 85]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.26. S-5.7.1 - System-call limitation
A system call may represent only part of a higher-level operation.
For example, a permitted socket write may form part of a larger
application transaction whose exact resource semantics are not
visible at the selected kernel interface.
Accordingly, the system must use an enforcement interface capable of
verifying the material attributes required by the applicable
enforcement point.
Where an application-specific transaction must be authorized, the
system may require a controlled application-level broker or resource
Finality Sink.
7.1.27. S-5.8 - Linux Security Module Implementation
In a Linux implementation, an applicable Linux Security Module may
enforce selected access-control decisions.
The LSM may restrict operations according to:
(a) process security identity; (b) resource security identity; (c)
permitted operation class; (d) security label; (e) task-associated
restriction; (f) protected policy state; or (g) other information
available to the supported enforcement interface.
In one variation, an LSM policy prevents an agent process from
directly modifying a protected resource and requires the operation to
be performed through a controlled host-side service.
In another variation, a suitable LSM enforcement hook participates
directly in the authorization procedure for an operation class it can
actually control.
7.1.28. S-5.8.1 - Protected-domain relationship
An LSM does not automatically constitute a PED merely because it
performs a permission check.
Where the kernel and its security state are protected from the
defined attacker, a kernel enforcement component may implement PED
functions consistent with the selected trust model.
Where the enforcement point requires additional cryptographic
isolation or protection against a compromised host kernel, an LSM
alone may be insufficient.
Das Expires 25 April 2027 [Page 86]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.29. S-5.8.2 - Authorization state
The kernel enforcement component may maintain:
| x | Current policy generation. |
| - | ------------------------------------------- |
| x | Agent-associated security context. |
| x | Resource permission state. |
| x | Revocation generation. |
| x | Operation-specific authorization reference. |
| x | Resource-state version. |
| x | Protected operation status. |
The implementation must specify which of these fields are relied upon
and how unauthorized processes are prevented from modifying them.
7.1.30. S-5.9 - eBPF Observation and Enforcement
An implementation may employ eBPF programs to observe or, at
supported attachment points, enforce selected kernel security
decisions.
eBPF-based observations may contribute to:
1. Process attribution. 2. Runtime behavioral descriptors. 3.
Network activity characterization. 4. Resource-access histories. 5.
Process-lineage information. 6. Detection of security-relevant
execution events.
A supported enforcement-capable attachment point may also permit a
program to deny or restrict particular operations.
7.1.31. S-5.9.1 - Observation is not enforcement
An eBPF tracepoint or tracing program that records an event after or
during execution does not inherently prevent the consequential
effect.
The implementation must distinguish between a telemetry mechanism and
a control path capable of enforcing a decision.
7.1.32. S-5.9.2 - Application semantic limitation
A kernel-level eBPF program may observe socket addresses, process
attributes, or selected packet information without possessing a
reliable representation of an application's final resource request.
Das Expires 25 April 2027 [Page 87]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where authorization depends on an HTTP body, cloud resource identity,
payment beneficiary, or other application-specific field, the system
must provide a trustworthy mechanism for obtaining and verifying that
field.
7.1.33. S-5.9.3 - Configuration integrity
The security architecture may restrict unauthorized detachment,
replacement, or modification of enforcement programs.
If the assumed attacker can disable the enforcement mechanism, the
claimed protection property may fail.
The corresponding embodiment must identify the protection against
such interference.
7.1.34. S-5.10 - Kernel-Controlled Protected State
A software-only implementation may maintain protected state in kernel
memory or in a privileged service whose modification is restricted by
the operating system.
A representative protected state structure includes:
KernelAuthorityStateID
AgentExecutionContextID
CurrentAuthorityGeneration
CurrentRevocationGeneration
PermittedOperationClass
ProtectedEvidenceReference
AuthorizedSinkReference
ConsumptionState
StateTransitionSequence
The protection is evaluated relative to the defined threat model.
Kernel-memory residency does not automatically establish resistance
to a kernel-level attacker.
Das Expires 25 April 2027 [Page 88]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A stronger implementation may move selected security-critical state
into hardware-protected storage or a cryptographically isolated
enforcement component.
7.1.35. PART III - HYPERVISOR ENFORCEMENT
7.1.36. S-5.11 - Hypervisor-Mediated Execution
A hypervisor may control one or more guest virtual machines executing
agent workloads.
The hypervisor may enforce restrictions using:
(a) virtualization of privileged processor operations; (b) guest
memory protection; (c) virtual device emulation or mediation; (d)
controlled virtual network interfaces; (e) protected virtual storage
interfaces;
(f) device assignment restrictions;
(g) selected virtual-machine exits; and
(h) other virtualization mechanisms supported by the platform.
The hypervisor may act as a trusted enforcement component relative to
a less-trusted guest.
7.1.37. S-5.11.1 - Trust separation
A guest operating-system administrator may be treated as untrusted
relative to the hypervisor.
The architecture may therefore prevent the guest from directly
modifying hypervisorcontrolled authorization state.
However, a hypervisor is not automatically protected against
compromise of its own privileged execution components.
Hardware-backed protection may be required for stronger adversarial
assumptions.
7.1.38. S-5.12 - Hypervisor Interception
The hypervisor may control selected guest operations through
virtualized interfaces.
1. 2. 3. 4. 5. 6. 7. 8.
Das Expires 25 April 2027 [Page 89]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Examples include:
Virtual network-device transmission. Virtual storage-device
requests. Protected memory-mapping changes. Device-assignment
operations. Virtual peripheral command submission. Selected
privileged instruction transitions. Hypervisor-controlled service
calls. Access to emulated hardware resources.
A hypervisor-controlled backend may capture a proposed operation
before permitting its specified consequential effect.
The resulting Candidate Act can be associated with the guest
identity, workload execution generation, and protected task context.
7.1.39. S-5.12.1 - Actual effect boundary
A hypervisor may observe a guest issuing a command without
necessarily controlling every subsequent physical effect.
For example, if a device has been assigned directly to a guest
through a hardware passthrough arrangement, some commands may bypass
ordinary hypervisor device emulation.
Where the selected enforcement point requires non-bypassable
finality, the deployment must account for such direct device access.
7.1.40. S-5.13 - Second-Stage Memory Protection
A hypervisor may employ second-stage address translation or another
supported memory protection mechanism to restrict guest access to
selected physical-memory regions.
Such protection may separate:
| x | Guest memory. |
| - | ------------------------------------ |
| x | Hypervisor memory. |
| x | Protected authorization records. |
| x | Device-control memory. |
| x | Shared-memory communication regions. |
An implementation may use memory access restrictions to protect
security-critical authorization state from guest modification.
Memory protection alone does not establish that all external
operations satisfy task-specific authorization.
Das Expires 25 April 2027 [Page 90]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The protected-finality mechanism may therefore operate in addition to
memory isolation.
7.1.41. S-5.14 - Hypervisor-Controlled Device Backend
In one implementation, a virtual device backend acts as a controlled
effectuation interface.
A guest submits a device operation through a virtualized command
queue.
The hypervisor or backend captures the operation and prevents the
governed physical effect while authorization is pending.
The operation is converted into a Candidate Act Descriptor.
The PED evaluates the required predicates.
After protected evidence commitment and scoped authorization, the
Finality Sink verifies the actual device operation.
Only an authorized command is transmitted to the underlying physical
device.
7.1.42. S-5.14.1 - Alternative backend
A virtual device may have multiple backends, failover routes, or
physical interfaces.
The implementation must ensure that the authorized effectuation path
cannot be bypassed by redirecting the operation to an uncontrolled
backend.
7.1.43. PART IV - HARDWARE-ASSISTED PROTECTION
7.1.44. S-5.15 - Hardware-Assisted PED
A PED may be implemented partly or entirely in hardware.
Examples include:
Das Expires 25 April 2027 [Page 91]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | A trusted execution environment. |
| - | ------------------------------------------------- |
| x | A secure enclave. |
| x | A hardware security module. |
| x | A protected coprocessor. |
| x | A secure firmware controller. |
| x | A programmable network security device. |
| x | A protected storage controller. |
| x | A hardware-enforced authorization register. |
| x | A combination of protected hardware and software. |
A hardware PED may perform selected authority checks, maintain
protected state, generate authenticated evidence, or activate scoped
authorization conditions.
7.1.45. S-5.15.1 - Hardware protection requirements
The implementation must identify:
1. What security-critical data is protected. 2. Which entity is
permitted to modify it. 3. Which adversary is excluded. 4. How
authorization state is updated. 5. How rollback or replay is
addressed where required. 6. How the effectuation controller
verifies the resulting authorization. 7. How failure and recovery
preserve the required security property.
A general assertion that hardware provides trust is insufficient to
describe the corresponding technical mechanism.
7.1.46. S-5.16 - Hardware Finality Sink
A hardware or firmware controller may serve as a Finality Sink where
it controls the specified consequential effect.
Possible examples include:
(a) a SmartNIC controlling network transmission; (b) a DPU
controlling selected I/O operations; (c) a storage controller
governing persistent writes; (d) a DMA controller governing memory
transfer; (e) an accelerator command controller; (f) a secure
cryptographic signing interface; (g) a hardware-controlled
communication interface; and (h) an industrial or robotic actuator
controller.
The Finality Sink verifies the applicable bounded authorization
condition before releasing the corresponding operation.
Das Expires 25 April 2027 [Page 92]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.47. S-5.16.1 - Queue admission versus physical execution
Authorization of command-queue admission and authorization of
physical command execution may correspond to different effectuation
boundaries.
The implementation must identify which effect is governed.
If a command already admitted to a hardware queue can execute after
authority revocation, a control applied only to future queue
admissions may be insufficient to prevent that outstanding effect.
A stronger implementation may require command fencing, protected
cancellation, queue quiescence, or operation-specific state
reconciliation.
7.1.48. S-5.17 - CIED Variation
A CIED may protect authority-critical operations through
cryptographic isolation and protected state handling.
In one implementation, a CIED:
1. Receives a validated Candidate Act Descriptor. 2. Obtains
protected authority state. 3. Evaluates the required predicates. 4.
Commits authenticated validation evidence. 5. Establishes scoped
non-bearer finality authority. 6. Protects the capability from
unauthorized modification. 7. Supplies verifiable authorization
information to the Finality Sink.
A CIED need not occupy the same physical component as the Finality
Sink.
Where the two are separated, their communication and state references
must preserve the relevant authorization bindings.
Where they are colocated, their distinct claimed functions must
remain identifiable.
7.1.49. PART V - CANDIDATE ACT AND NON-EFFECTIVE STAGING
7.1.50. S-5.18 - Candidate Act Formation
A governed operation may originate from:
Das Expires 25 April 2027 [Page 93]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) an agent process; (b) a child process; (c) a container; (d) a
guest virtual machine; (e) a host-side connector; (f) a delegated
worker; (g) a hardware command producer; (h) an asynchronous service;
or (i) another agent-associated execution component.
The interceptor creates a Candidate Act record before the specified
consequential effect.
A representative record includes:
CandidateActID = CA-0501
AgentContextID = AGENT-42
ExecutionContextID = EXEC-17
OperationClass = NETWORK_TRANSMIT
TargetResource = RESOURCE-81
AuthorityGeneration = 105
InterceptionPoint = KERNEL-NET-02
IntendedSink = FS-NET-05
CandidateStatus = STAGED
The values are illustrative.
7.1.51. S-5.19 - Non-Effective Holding
A kernel or hypervisor implementation may maintain an operation in a
Non-Effective State through a controlled mechanism such as:
1. A pending resource request. 2. A withheld network message. 3. A
staged storage operation. 4. A controlled virtual-device queue. 5.
A broker-owned operation buffer. 6. A disabled device-admission
entry. 7. An uncommitted resource transaction. 8. A protected
pending-command record.
The staging mechanism must actually prevent the specified effect.
A logging mechanism that records the operation after it has already
occurred does not establish NES.
Das Expires 25 April 2027 [Page 94]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.52. S-5.19.1 - Non-blocking enforcement variation
Some operating-system hooks cannot suspend an operation while an
external authorization service performs an arbitrary-length
validation.
For such a platform, the embodiment may use a protected broker that
receives and stages the operation outside the restricted kernel hook.
Alternatively, the kernel may make a bounded decision using already
available protected authorization state.
The implementation must avoid assuming that every kernel hook
supports synchronous remote authorization.
7.1.53. S-5.20 - Candidate Act Descriptor
A representative descriptor includes:
| x | Candidate Act identifier. |
| - | -------------------------------- |
| x | Authenticated execution context. |
| x | Process or workload generation. |
| x | Operation class. |
| - | ------------------------------------- |
| x | Actual or proposed resource identity. |
| x | Material operation parameters. |
| x | Canonical payload digest. |
| x | Authority generation. |
| x | Resource-state version. |
| x | Intended Finality Sink. |
| x | Replay-control reference. |
| x | Applicable expiration. |
| x | Canonicalization profile. |
The material fields must be selected according to the operation
class.
A file operation may require stable object identity.
A network operation may require destination and application-request
correspondence.
A device operation may require command parameters and hardware target
identity.
Das Expires 25 April 2027 [Page 95]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.54. PART VI - PROTECTED VALIDATION
7.1.55. S-5.21 - PED Authorization Procedure
The PED obtains the Candidate Act Descriptor and applicable protected
authority state.
It evaluates the predicates required for the relevant operation.
Such predicates may include:
1. Agent identity. 2. Workload identity. 3. Task authorization. 4.
Resource identity. 5. Operation class. 6. Delegation context. 7.
Purpose or policy scope. 8. Authority generation. 9. Revocation
state. 10. Runtime security condition. 11. Resource-state
precondition. 12. Quota or usage constraint. 13. Hardware device
security state. 14. Required human approval. 15. Effectuation-
boundary identity.
The predicate set may be selected according to the resource and
effect being governed.
7.1.56. S-5.22 - Protected Validation Evidence
Following successful validation, the PED creates or commits protected
validation evidence.
A representative record comprises:
EvidenceID = VE-0501
CandidateActID = CA-0501
DescriptorDigest = DIGEST-0501
PEDIdentity = PED-KERNEL-01
PolicyGeneration = 105
ValidationResult = APPROVED
AuthorizedSink = FS-NET-05
EvidenceGeneration = 910
The evidence may be implemented as a protected registry entry,
authenticated record, signed receipt, sealed state transition, or
hardware-backed commitment.
Das Expires 25 April 2027 [Page 96]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where the applicable enforcement point requires evidence commitment
before capability release, that ordering is enforced.
7.1.57. S-5.23 - Scoped Non-Bearer Finality Capability
The PED establishes or activates bounded finality authority
associated with the validated operation.
A representative capability contains or references:
CapabilityID = CAP-0501
CandidateActID = CA-0501
EvidenceReference = VE-0501
AuthorizedSinkID = FS-NET-05
AuthorizedResource = RESOURCE-81
AuthorizedOperation = NETWORK_TRANSMIT
AuthorityGeneration = 105
UsagePolicy = SINGLE_USE
CapabilityStatus = ACTIVE
The capability may be represented by:
(a) a protected authorization-table entry; (b) a signed or
authenticated object; (c) an integrity-protected state-machine
transition; (d) a secure register;
(e) a hardware authorization latch;
(f) a protected queue permission; or
(g) another technically enforced bounded authorization condition.
The capability need not be a portable bearer token.
7.1.58. PART VII - FINALITY SINK VERIFICATION
Das Expires 25 April 2027 [Page 97]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.59. S-5.24 - Finality Sink Positioning
A kernel, hypervisor, or hardware implementation places the Finality
Sink at a point capable of controlling the designated consequential
effect.
The Finality Sink may be:
1. A protected kernel-controlled resource operation. 2. A
privileged broker. 3. A hypervisor-controlled device backend. 4. A
protected network gateway. 5. A storage-commit controller. 6. A
secure credential-use interface. 7. A hardware device-admission
controller. 8. A firmware-controlled actuator interface.
The sink's authority is determined by its control over the actual
effectuation path.
A component is not a Finality Sink for a given effect merely because
it can observe the operation.
7.1.60. S-5.25 - Actual Pending Operation Reconstruction
The Finality Sink obtains or reconstructs the material properties of
the operation it is about to effectuate.
For a network operation, this may include:
| x | Effective source execution context. |
| - | --------------------------------------------------- |
| x | Intended or final destination. |
| x | Network protocol. |
| x | Destination address and port. |
| x | Application-level request identity where available. |
| x | Payload digest or trustworthy equivalent. |
| x | Actual output interface. |
For a storage operation, this may include:
| x | Actual resource object. |
| - | ------------------------------- |
| x | Intended modification. |
| x | Current resource-state version. |
| x | Write scope. |
| x | Commit interface. |
For a hardware command, this may include:
Das Expires 25 April 2027 [Page 98]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Target device. |
| - | ---------------------------- |
| x | Command class. |
| x | Relevant command parameters. |
| x | Execution queue. |
| x | Device authority generation. |
| x | Applicable hardware state. |
7.1.61. S-5.25.1 - Independent source of operation information
The sink does not rely exclusively on an agent's unverified statement
describing what it intends to perform.
The actual operation may be derived from a controlled kernel object,
immutable command buffer, protected backend queue, resource
controller, or other trustworthy representation.
Where the operation is transformed after initial validation, the
final material parameters must remain within the permitted
authorization scope.
7.1.62. S-5.26 - Sink-Local Protected State
A representative sink-local state record contains:
SinkID
CandidateActID
CapabilityID
ExpectedDescriptorDigest
AuthorityGeneration
RevocationGeneration
ConsumptionState
ResourceStateReference
DispatchStatus
CompletionStatus
A single-use capability may transition:
UNUSED → RESERVED → CONSUMED
Das Expires 25 April 2027 [Page 99]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The protected transition must prevent unauthorized concurrent use.
Where a local authorization is consumed before a remote operation's
result becomes known, an INDETERMINATE state may be maintained until
the external outcome is reconciled.
7.1.63. PART VIII - EFFECTUATION-PATH COMPLETENESS
7.1.64. S-5.27 - Effectuation-Path Enumeration
A system asserting non-bypassable enforcement identifies the
technical paths through which the governed effect can occur.
For example, a network effect may be produced through:
(a) ordinary socket transmission; (b) an existing connected socket;
(c) a host-side proxy; (d) a privileged service; (e) a directly
assigned network device; (f) a virtual-device backend; (g) a kernel
tunneling mechanism;
(h) an asynchronous service worker; or
(i) another available egress path.
A protected-finality deployment must ensure that the relevant paths
are restricted, mediated, or excluded according to the guarantee.
7.1.65. S-5.28 - Enforcement-Path Coverage State
The system may maintain an Effectuation Path Coverage Record
including:
EffectClass
SourceExecutionClass
KnownEffectuationPaths
RequiredEnforcementPoints
CurrentPolicyGeneration
DeviceAssignmentState
ApplicableBypassRestrictions
CoverageStatus
Das Expires 25 April 2027 [Page 100]
Internet-Draft Kernel-Hardware Execution Finality October 2026
VerificationSequence
A coverage verification may be performed during initialization and
following relevant configuration changes.
7.1.66. S-5.28.1 - Configuration changes
Coverage may need to be re-evaluated following:
1. Network-interface creation. 2. Device pass-through. 3. Kernel
module changes. 4. Hypervisor backend replacement. 5. Installation
of a new privileged tool service. 6. Creation of a new IPC route. 7.
Resource mount changes. 8. Policy changes. 9. Runtime migration.
10. Hardware reconfiguration.
An earlier coverage result does not automatically prove continued
coverage after a material configuration change.
7.1.67. PART IX - PRINCIPAL EXECUTION WORKFLOW
7.1.68. S-5.29 - Complete 24-Step Workflow
7.1.69. Step S5-01 - Execution environment initialization
The system establishes the operating-system, optional hypervisor, and
relevant protected enforcement components.
7.1.70. Step S5-02 - Trust-boundary configuration
The system identifies which execution contexts are trusted to
maintain the required protected state.
7.1.71. Step S5-03 - Kernel or hypervisor enforcement activation
The required interception and restriction mechanisms are configured.
7.1.72. Step S5-04 - Effectuation-path coverage verification
The system checks that designated consequential effects cannot occur
through prohibited alternative paths.
7.1.73. Step S5-05 - Agent execution-context registration
The agent, workload, task, and applicable authority generation are
associated with authenticated execution state.
Das Expires 25 April 2027 [Page 101]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.74. Step S5-06 - Agent computation
The agent performs ordinary computation.
7.1.75. Step S5-07 - Consequential operation generation
The agent generates a governed operation.
7.1.76. Step S5-08 - Operation interception
The operation reaches the controlled kernel, hypervisor, or broker
interface.
7.1.77. Step S5-09 - Origin authentication
The system establishes the actual originating workload context.
7.1.78. Step S5-10 - Candidate Act construction
The system assigns the operation a Candidate Act identity.
7.1.79. Step S5-11 - Non-effective staging
The governed effect is withheld.
7.1.80. Step S5-12 - Descriptor canonicalization
The operation is represented using the applicable deterministic
descriptor format.
7.1.81. Step S5-13 - Protected-domain submission
The descriptor and authenticated context are supplied to the PED.
7.1.82. Step S5-14 - Protected authority-state retrieval
The PED obtains current required authority and revocation
information.
7.1.83. Step S5-15 - Predicate evaluation
The PED evaluates all mandatory authorization conditions.
7.1.84. Step S5-16 - Evidence commitment
The PED commits protected validation evidence.
Das Expires 25 April 2027 [Page 102]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.85. Step S5-17 - Bounded capability activation
A scoped non-bearer finality capability is established.
7.1.86. Step S5-18 - Finality Sink presentation
The staged operation is presented to the authorized effectuation
controller.
7.1.87. Step S5-19 - Actual-operation reconstruction
The sink obtains the actual material operation parameters.
7.1.88. Step S5-20 - Finality verification
The sink verifies the required evidence, capability bindings, current
state, and operation correspondence.
7.1.89. Step S5-21 - Protected authorization-state transition
The sink reserves or consumes the applicable bounded authorization.
7.1.90. Step S5-22 - Controlled effectuation
The authorized operation is performed.
7.1.91. Step S5-23 - Completion-state observation
The resulting operation status is obtained where available.
7.1.92. Step S5-24 - Recovery-state reconciliation
Protected operation state is updated or retained for reconciliation
if the external outcome is uncertain.
7.1.93. PART X - REPRESENTATIVE ALGORITHMS
7.1.94. S-5.30 - Algorithm A: Enforcement Initialization
function InitializeKernelHypervisorEnforcement(profile):
trusted_components = ResolveTrustedComputingBase(profile)
protected_domains = InitializeProtectedDomains(profile)
enforcement_points = InstallSupportedEnforcementControls(
profile.operation_classes )
Das Expires 25 April 2027 [Page 103]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if not VerifyEnforcementControlIntegrity(enforcement_points):
return DENIED effect_paths =
EnumerateGovernedEffectuationPaths(profile)
if not VerifyRequiredPathCoverage(
effect_paths, enforcement_points ):
return DENIED
generation = AllocateAuthorityGeneration()
CommitProtectedConfigurationState({
profile: profile.id, authority_generation: generation,
enforcement_points: enforcement_points, effect_paths: effect_paths })
return ACTIVE
The implementation must define the control-integrity and path-
coverage tests for the selected operating system or hypervisor.
A generic statement that all relevant paths have been verified is not
a substitute for actual configuration-specific coverage checking.
S-5.31 - Algorithm B: Kernel or Hypervisor Candidate Act Capture
function CaptureGovernedOperation(source, request):
context = AuthenticateExecutionContext(source)
if context is invalid:
return DENIED
operation = CaptureControlledOperationRepresentation(request)
if not IsGovernedEffect(operation):
return EvaluateApplicableNonFinalityPolicy(operation)
candidate_id = AllocateCandidateActID()
descriptor = Canonicalize({
Das Expires 25 April 2027 [Page 104]
Internet-Draft Kernel-Hardware Execution Finality October 2026
candidate_id: candidate_id, execution_context: context, operation:
operation, authority_generation: CurrentAuthorityGeneration(context),
target_sink: ResolveRequiredSink(operation) })
StageWithoutEffectuation(candidate_id, operation, descriptor)
return PED.Validate(candidate_id, descriptor)
The selected interception point must support the required holding
semantics.
If an operating-system hook cannot safely stage the operation, the
request may instead be redirected to a controlled broker that
performs the staging.
7.1.95. S-5.32 - Algorithm C: Protected Validation
function ValidateCandidate(candidate_id, descriptor):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != STAGED:
return DENIED
if not VerifyAuthenticatedContextBinding(descriptor, record):
return DENIED
authority = ProtectedAuthorityRegistry.lookup(descriptor)
if not EvaluateRequiredPredicates(descriptor, authority):
ProtectedOperationRegistry.deny(candidate_id) return DENIED evidence
= CommitProtectedValidationEvidence(
candidate_id, descriptor, authority )
capability = CreateScopedFinalityCapability({
candidate_id: candidate_id, descriptor_digest: Hash(descriptor),
evidence_reference: evidence.id, authorized_sink:
descriptor.target_sink, authorized_scope: authority.permitted_scope,
authority_generation: authority.generation })
if not AtomicallyActivateAuthorization(
candidate_id, evidence, capability ):
Das Expires 25 April 2027 [Page 105]
Internet-Draft Kernel-Hardware Execution Finality October 2026
DisableCapability(capability) return DENIED
return AUTHORIZED
The corresponding protected state transition must ensure that a
failed activation does not leave an independently usable capability.
7.1.96. S-5.33 - Algorithm D: Finality Sink Enforcement
function ExecuteAtFinalitySink(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED
actual_operation = ObtainActualPendingOperation(candidate_id)
if actual_operation is unavailable:
return DENIED
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
if not VerifyProtectedEvidence(evidence):
return DENIED if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED
if not VerifyActualOperationBinding(
actual_operation, capability ):
return DENIED
if not VerifyCurrentAuthorityState(capability):
return DENIED
Das Expires 25 April 2027 [Page 106]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if not VerifySinkLocalConsumptionState(capability):
return DENIED
if not AtomicallyReserveAuthorization(capability):
return DENIED result =
DispatchThroughControlledEffectuationInterface(
actual_operation )
ReconcileOperationOutcome(candidate_id, result)
return result
For an external resource lacking atomic integration with the
protected authorization registry, dispatch and completion may require
separate durable states.
S-5.34 - Algorithm E: Revocation and Enforcement Generation
function RevokeAgentAuthority(agent_context, restricted_scope):
new_generation = AdvanceProtectedAuthorityGeneration(
agent_context )
affected_paths = ResolveAffectedEffectuationPaths(
agent_context, restricted_scope )
for each path in affected_paths:
ApplyRestrictiveEnforcementUpdate(
path, new_generation, restricted_scope )
acknowledgments = CollectEnforcementState(
affected_paths, new_generation )
if not VerifyRequiredConvergence(acknowledgments):
ApplyCompensatingRestrictions(affected_paths)
MarkPriorAuthorizationsAccordingToRevocationPolicy(
agent_context, new_generation )
Das Expires 25 April 2027 [Page 107]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return EvaluateRestrictiveConvergence(
affected_paths, new_generation )
The system must not declare a restriction fully converged merely
because a central policy record has been updated.
Where already queued hardware or asynchronous operations are included
in the governed scope, the corresponding in-flight state must also be
addressed.
S-5.35 - Algorithm F: Kernel/Hypervisor State Recovery
function RecoverProtectedEnforcementState():
generation = LoadCurrentProtectedAuthorityGeneration()
registry = RecoverProtectedOperationRegistry()
sinks = EnumerateRequiredFinalitySinks()
for each sink in sinks:
recovered_state = RecoverOrVerifySinkState(sink)
if recovered_state is invalid:
RestrictAffectedEffectuationPaths(sink) continue
ReconcileOutstandingOperations(
sink, registry, recovered_state )
if not VerifyRequiredEnforcementCoverage():
return RESTRICTED
return ACTIVE
Recovery must preserve applicable protected consumption and
revocation state.
Restoring an older software configuration must not silently
reactivate authority that has already been revoked or consumed.
Das Expires 25 April 2027 [Page 108]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.97. PART XI - WORKED TECHNICAL EXAMPLES
S-5.36 - Example A: Kernel-Mediated Protected File Modification
The following is a hypothetical example.
An enterprise AI coding agent executes as a restricted process.
The agent requests modification of a protected application
configuration file.
An applicable operating-system security control prevents direct
modification of the protected file.
The request is submitted to a controlled file-operation broker.
The broker creates a Candidate Act identifying:
| x | Originating agent. |
| - | ----------------------- |
| x | Task identity. |
| x | Actual target resource. |
| x | Requested modification. |
| x | Content digest. |
| - | --------------------------------------- |
| x | Current policy generation. |
| x | Required storage effectuation boundary. |
The PED evaluates whether the agent is authorized to make the
specified modification.
Protected validation evidence is committed.
A scoped non-bearer capability is established.
The file-commit Finality Sink verifies the actual selected file
object and the authorized modification.
The protected authorization is consumed.
The controlled interface performs the permitted modification.
The example does not require every ordinary file write performed by
the agent to undergo this procedure; it applies to the selected
governed resource class.
S-5.37 - Example B: Hypervisor-Controlled Network Transmission
Das Expires 25 April 2027 [Page 109]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A virtual-machine-isolated agent generates a network request.
The request reaches a hypervisor-controlled virtual network backend.
The backend captures the request before external transmission.
The request is placed in a controlled holding buffer.
The PED evaluates its authorized destination, resource scope, and
applicable execution context.
Protected validation evidence is committed.
A bounded finality capability is established.
A protected network Finality Sink verifies the actual pending
transmission and required authorization.
The authorized request is transmitted.
If the guest attempts to use a directly assigned network device that
bypasses the protected backend, the deployment must either prevent
the route or use an additional protected enforcement mechanism.
S-5.38 - Example C: Kernel Observation Without Finality Enforcement
An AI agent executes a process that sends confidential information
through an otherwise permitted network connection.
A kernel tracing mechanism records the network activity.
The information has already been transmitted before the monitoring
service analyzes the event.
This represents observation or retrospective detection, not
preventive finality enforcement for the transmitted information.
In a protected-finality variation, the controlled network or
application interface must withhold the governed transmission pending
the required authorization and sink verification.
The distinction depends on the actual technical enforcement position,
not the presence of a kernel event record.
7.1.98. S-5.39 - Example D: Hardware Command Queue
An agent requests a hardware operation through a virtualized device
interface.
Das Expires 25 April 2027 [Page 110]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The operation is staged before admission to the device execution
queue.
The PED validates the permitted command class, target device,
resource scope, and current authority generation.
Protected validation evidence is committed.
A scoped capability is established.
The hardware or firmware Finality Sink verifies the actual command
descriptor.
If authorization succeeds, the command is admitted according to the
permitted queue-control procedure.
If the applicable security policy requires revocation of commands
already admitted to the queue, additional fencing, cancellation, or
queue-state mechanisms are employed.
Authorization of new admissions alone does not automatically cancel
previously admitted commands.
S-5.40 - Example E: Kernel Policy Revocation During Agent Execution
An agent has previously obtained authority for a bounded class of
network operations.
A protected risk or security controller reduces the agent's
authority.
The system advances the applicable authority generation.
Affected kernel, gateway, or device enforcement points receive the
restrictive update.
A pending operation attempts effectuation using an authorization
associated with the earlier generation.
The Finality Sink checks the applicable revocation and generation
conditions.
If the earlier authorization is no longer valid, effectuation is
denied.
Where the security requirement includes already queued asynchronous
operations, those operations are also restricted or reconciled under
the applicable revocation procedure.
Das Expires 25 April 2027 [Page 111]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.99. PART XII - FAILURE AND ADVERSARIAL SCENARIOS
7.1.100. S-5.41 - Representative Failure Cases
7.1.101. F1 - Uncontrolled System-Call Path
A proposed operation reaches an allowed system call that bypasses the
intended protected resource interface.
The deployment must identify and mediate or restrict the relevant
effectuation path.
7.1.102. F2 - Kernel Hook Not Supporting Required Mediation
A selected kernel hook cannot safely defer a request while external
authorization occurs.
The implementation must employ supported bounded kernel-side
authorization or redirect the operation through a controlled staging
broker.
It must not assume unsupported blocking behavior.
7.1.103. F3 - eBPF Observation Without Enforcement
An eBPF program records an unauthorized operation but does not
prevent it.
The observation does not satisfy the claimed preventive finality
condition.
7.1.104. F4 - Unauthorized Enforcement-Program Removal
An attacker disables or replaces a required enforcement program.
The selected protection architecture must prevent, detect, or fail
safely upon that change according to the threat model.
7.1.105. F5 - Kernel-Level Compromise
An attacker compromises the trusted operating-system kernel.
A kernel-only protected-state implementation may lose the required
isolation.
Stronger enforcement points require additional protection suited to
that adversary.
Das Expires 25 April 2027 [Page 112]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.106. F6 - Guest Kernel Compromise
An attacker compromises the guest operating system.
A properly protected hypervisor-side enforcement arrangement
continues to apply its restrictions where the corresponding
hypervisor and device-control components remain trustworthy.
7.1.107. F7 - Device Pass-Through
A guest gains direct access to an effect-capable device bypassing the
virtual device backend.
The system restricts the pass-through path or enforces the required
authorization at an appropriate downstream controller.
7.1.108. F8 - Memory Modification After Validation
An agent modifies command or payload memory after initial
authorization.
The Finality Sink uses a stable representation or reconstructs the
actual pending operation.
7.1.109. F9 - Resource Identifier Substitution
The operation targets a different effective resource than the one
previously authorized.
The mismatch is detected before effectuation.
7.1.110. F10 - Authority Generation Mismatch
The capability refers to a superseded authority generation.
The Finality Sink applies the required generation and revocation
rule.
7.1.111. F11 - Capability Replay
A previously consumed single-use authorization is presented again.
Protected sink-local state denies replay.
7.1.112. F12 - Concurrent Capability Use
Two workers attempt to use the same single-use capability.
Das Expires 25 April 2027 [Page 113]
Internet-Draft Kernel-Hardware Execution Finality October 2026
An atomic protected transition prevents unauthorized duplicate
consumption.
7.1.113. F13 - Hardware Queue Already Contains Commands
A restrictive policy update occurs after a command has been admitted.
The system must account for the outstanding command when the claimed
restriction requires prevention of its effect.
7.1.114. F14 - Hypervisor Backend Replacement
A virtual device backend is replaced or reconfigured.
The effectuation-path coverage state is re-evaluated before
unrestricted governed operation resumes.
7.1.115. F15 - Kernel Policy Reload
A security policy is replaced or reloaded.
The system preserves required restrictions during the transition and
avoids a permissive enforcement gap.
7.1.116. F16 - PED Unavailability
The protected authorization service becomes unavailable.
The governed operation remains withheld, denied, or canceled
according to its fail-closed policy.
7.1.117. F17 - Finality Sink Failure
The designated effectuation controller becomes unavailable.
The system does not release the governed effect through an
uncontrolled alternative path.
7.1.118. F18 - Protected State Rollback
A recovery process restores stale authorization state.
A protected generation, authenticated state reference, or equivalent
mechanism detects or prevents prohibited rollback.
Das Expires 25 April 2027 [Page 114]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.119. F19 - Asynchronous Worker Continuation
A queued operation is executed after the originating agent loses
authority.
The relevant continuation or finality authorization is verified
before the governed effect.
7.1.120. F20 - Indeterminate External Completion
The sink transmits an authorized operation but does not receive a
definitive completion acknowledgment.
The system preserves an unresolved outcome and applies the defined
reconciliation mechanism.
7.1.121. F21 - Kernel Resource Exhaustion
The kernel enforcement mechanism encounters resource exhaustion or
insufficient processing capacity.
The system applies a defined restriction or denial policy rather than
silently treating incomplete verification as authorization.
7.1.122. F22 - Hypervisor Migration
A guest is migrated to another physical host.
The destination enforcement environment verifies the applicable
authority context, protected state, and effectuation-path controls
before continuing governed operations.
7.1.123. F23 - Protected Credential Path Bypass
A privileged credential remains accessible through an unmediated
kernel or device interface.
The deployment must constrain the credential-use path or enforce the
applicable finality condition at a suitable protected boundary.
7.1.124. F24 - Inconsistent Multi-Sink Revocation
A policy update reaches one Finality Sink but not another.
The authority-convergence mechanism must identify the inconsistency
and apply the restrictions required by the claimed distributed
revocation semantics.
Das Expires 25 April 2027 [Page 115]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.125. PART XIII - SOFTWARE, FIRMWARE, HARDWARE, AND DISTRIBUTED
VARIATIONS
7.1.126. S-5.42 - Kernel-Only Software Implementation
The agent executes on a conventional operating system.
Kernel security mechanisms restrict direct resource access.
A protected host-side service performs authorization.
A kernel-controlled or broker-controlled resource interface acts as
the Finality Sink.
The trust model assumes the integrity of the relevant kernel and
privileged components.
7.1.127. S-5.43 - Hypervisor-Only Enforcement Implementation
One or more agents execute within guest virtual machines.
The hypervisor controls selected guest device and resource
interfaces.
Protected authorization state is maintained within a hypervisor-
controlled domain.
A virtual device backend or equivalent protected interface verifies
authorization before releasing the governed effect.
This variation assumes the integrity of the relevant hypervisor
components.
7.1.128. S-5.44 - Kernel and Hypervisor Cooperative Implementation
The guest kernel performs preliminary operation classification.
The hypervisor independently controls an applicable effectuation
interface.
The PED evaluates protected authorization predicates.
The Finality Sink verifies the actual operation.
The cooperation may reduce the number of operations requiring
expensive protected authorization while preserving required
enforcement for consequential operations.
Das Expires 25 April 2027 [Page 116]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The applicable implementation must ensure that a guest kernel cannot
disable required hypervisor-level restrictions.
7.1.129. S-5.45 - TEE-Backed PED Implementation
A TEE maintains selected protected authorization state or validation
logic.
A kernel or hypervisor component submits Candidate Acts.
The TEE validates the required conditions and establishes protected
evidence and bounded finality enablement.
A controlled effectuation interface verifies the corresponding
authorization.
The technical mechanism must prevent an untrusted component from
simply bypassing the Finality Sink.
7.1.130. S-5.46 - HSM-Backed Enforcement Implementation
| An HSM maintains protected keys, state commitments, or authorization logic. The host or hypervisor submits protected operation representations. The HSM performs the required protected functions. The effectuation controller verifies the resulting authorization before executing the governed operation. Merely requesting an HSM signature without operation-specific enforcement does not necessarily satisfy the relevant protected-finality requirements. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-5.47 - SmartNIC/DPU Finality Implementation The agent executes on a host or virtual machine. A SmartNIC or DPU controls selected network transmissions. A PED validates the intended operation and establishes bounded authorization. The protected device verifies the relevant authorization before transmission. Where the authorization concerns application-specific parameters, the implementation must provide trustworthy access to those parameters. |
| S-5.48 - Storage-Controller Finality Implementation The agent requests a persistent storage modification. A protected storage controller or equivalent commit interface receives the pending operation. The controller verifies the required authorization state. The operation becomes persistent only according to the authorized storage procedure. The implementation must address relevant caching, writeback, journal, and crash-recovery behavior when the claimed effect is durable storage commitment. |
7.1.131. S-5.49 - Accelerator and DMA Enforcement Implementation
The agent submits work to an accelerator or requests memory transfer
through a DMAcapable interface.
A protected controller associates the command with the originating
execution context and applicable authority generation.
The controller verifies authorization before the governed admission
or execution boundary.
The implementation may employ an IOMMU, protected device queue,
command-context tag, secure register, or equivalent hardware-
supported control.
The required protection must be established for the actual selected
hardware operations.
7.1.132. S-5.50 - Distributed PED and Finality Sink
The PED executes on one computing node.
Das Expires 25 April 2027 [Page 117]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The Finality Sink controls a resource on another node.
The nodes exchange protected authorization references and operation
descriptors through an authenticated communication mechanism.
The Finality Sink verifies the required protected authorization
against the actual pending operation.
The distributed implementation must address replay, network
partitions, stale authority, incomplete state transitions, and
recovery.
7.1.133. S-5.51 - Colocated PED and Finality Sink
A kernel component, protected hypervisor service, hardware
controller, or secure processing module may implement both PED and
Finality Sink roles.
The implementation preserves the distinct logical functions required
by the applicable enforcement point.
No physically separate authorization server is required merely
because the enforcement point names multiple functional stages,
unless physical separation is expressly required.
7.1.134. PART XIV - TECHNICAL DATA STRUCTURES
7.1.135. S-5.52 - ExecutionContextRecord
The record may contain:
1. 2. 3. 4. 5. 6. 7. 8. 9.
ExecutionContextID. AgentContextID. TaskID. ProcessOrVMGeneration.
SecurityDomainID. AuthorityGeneration. PermittedOperationClasses.
TrustedOriginReference. LifecycleStatus.
7.1.136. S-5.53 - EnforcementPointRecord
The record may contain:
1. EnforcementPointID. 2. KernelOrHypervisorInterface. 3.
ControlledOperationClass. 4. ControlledEffectuationPath. 5.
PolicyGeneration. 6. ProtectionState. 7. RequiredPEDReference. 8.
RequiredSinkReference. 9. CurrentCoverageStatus.
Das Expires 25 April 2027 [Page 118]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.137. S-5.54 - CandidateActRecord
The record may contain:
1. CandidateActID. 2. ExecutionContextID. 3. OperationClass. 4.
TargetResource. 5. ActualOperationReference. 6. DescriptorDigest.
7. AuthorityGeneration. 8. IntendedSinkID. 9. CandidateStatus.
7.1.138. S-5.55 - ProtectedValidationEvidenceRecord
The record may contain:
1. EvidenceID. 2. CandidateActID. 3. DescriptorDigest. 4.
PEDIdentity. 5. PolicyGeneration. 6. ValidationResult. 7.
EvidenceCommitment. 8. EvidenceGeneration.
9. AuthorizedSinkID.
7.1.139. S-5.56 - ScopedFinalityCapabilityRecord
The record may contain:
1. 2. 3. 4. 5. 6. 7. 8. 9.
CapabilityID. CandidateActID. EvidenceReference.
AuthorizedOperationScope. AuthorizedResource. AuthorizedSinkID.
AuthorityGeneration. UsagePolicy. CapabilityStatus.
7.1.140. S-5.57 - SinkLocalStateRecord
The record may contain:
1. SinkID. 2. CandidateActID. 3. CapabilityID. 4.
ExpectedOperationDigest. 5. AuthorityGeneration. 6.
RevocationGeneration. 7. ConsumptionState. 8. DispatchState. 9.
CompletionReference.
7.1.141. S-5.58 - EffectuationPathCoverageRecord
The record may contain:
1. EffectClass. 2. SourceExecutionClass. 3.
KnownEffectuationPaths. 4. RequiredEnforcementPoints. 5.
CoverageGeneration. 6. DeviceAssignmentState. 7.
AlternatePathRestrictionState. 8. CoverageVerificationResult.
Das Expires 25 April 2027 [Page 119]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.142. S-5.59 - HardwareOperationRecord
The record may contain:
1. HardwareCommandID. 2. OriginatingExecutionContext. 3.
DeviceIdentity.
4. CommandClass. 5. CommandDescriptorDigest. 6. QueueIdentity. 7.
AuthorityGeneration. 8. AdmissionStatus. 9. CompletionStatus. 10.
RevocationOrFencingState.
7.1.143. S-5.60 - RecoveryStateRecord
The record may contain:
1. RecoveryGeneration. 2. LastProtectedAuthorityGeneration. 3.
RequiredEnforcementPointReferences. 4.
OutstandingOperationReferences. 5. ProtectedConsumptionReferences.
6. UnresolvedExternalOperationReferences. 7.
CoverageVerificationStatus. 8. RecoveryCompletionStatus.
These records may be implemented using protected kernel memory,
hypervisor state, authenticated storage, protected databases,
hardware registers, secure-controller memory, or cooperating
distributed state components.
7.1.144. PART XV - implementer VERIFICATION TESTS
7.1.145. S-5.61 - Representative Engineering Verification Procedures
The following are proposed test procedures, not representations of
tests already conducted.
7.1.146. Test Technical condition
T1 Authorized kernel-mediated
operation T2 Unauthorized operation T3 Missing finality capability T4
Replayed single-use capability T5 Altered command descriptor T6 Guest
attempts hypervisor bypass T7 Device pass-through path T8 eBPF
observational-only event T9 Kernel hook unavailable T10 Enforcement
program removed T11 Kernel state rollback
Das Expires 25 April 2027 [Page 120]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.1.147. Expected behavior
Effectuation permitted Effectuation denied Governed effect withheld
Rejected Mismatch detected Restricted or mediated Governed path
coverage enforced Not falsely treated as preventive enforcement
Required control fails safely Protection loss prevented or detected
according to threat model Stale authority rejected
T12 Concurrent capability consumption Atomic usage restriction
enforced T13 Authority generation revoked T14 Hardware command
already queued Required fencing or continuation rule applied T15
Hypervisor device backend changed Coverage reverified T16 File object
substituted T17 Mutable payload altered T18 PED unavailable T19 Sink
unavailable T20 Kernel enforcement resource
exhaustion
T21 Hypervisor migration T22 Remote external result uncertain T23
Multiple Finality Sinks inconsistent Required convergence
restrictions applied T24 Host-kernel compromise T25 Guest kernel
compromise T26 Hardware device control failure T27 Credential-use
interface bypass T28 Recovery following protected
service restart
Invalid authorization withheld
Effective resource checked Actual operation reverified No permissive
fallback No uncontrolled effectuation Defined restrictive behavior
Enforcement state re-established Reconciliation required
Trust-model limitations verified Protected hypervisor control
evaluated Defined restriction or containment state Protected
effectuation path maintained Consumption and revocation state
preserved
The actual implementation must identify supported kernel, hypervisor,
and hardware primitives appropriate to the selected platform.
7.1.148. PART XVI - Enforcement-Point Mapping and Technical
Correspondence
7.1.149. S-5.62 - Enforcement-Point Mapping and Technical
Correspondence
this implementation profile may support technical limitations
relating to:
Das Expires 25 April 2027 [Page 121]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) protected AI-agent execution; (b) kernel and hypervisor
enforcement; (c) operating-system security hooks; (d) protected
Candidate Act staging; (e) non-effective operation control; (f)
protected PED or CIED validation; (g) protected validation evidence;
(h) scoped non-bearer finality capabilities;
(i) Finality Sink verification;
(j) actual pending operation reconstruction;
(k) kernel and device effectuation-path restrictions;
(l) process and workload attribution;
(m) hardware-assisted authority enforcement;
(n) cross-device authority generations;
(o) revocation and protected-state consistency;
(p) runtime behavioral observations;
(q) hardware command control;
(r) recovery and asynchronous operation management; and
(s) software, firmware, and hardware deployment alternatives.
In particular, the embodiment provides representative implementation
material relevant to the sandbox-finality, effectuation-path
completeness, atomic inline finality, process-lineage, hardware
containment, and cross-device enforcement enforcement point families.
The exact correspondence must be established through a limitation-by-
limitation mapping against the finalized enforcement points.
7.1.150. PART XVII - implementer IMPLEMENTATION REQUIREMENTS
7.1.151. S-5.63 - Complete Implementation Checklist
For an actual implementation, a person having ordinary skill in the
art identifies:
1. The computing platform and processor architecture. 2. The
operating system and supported kernel version. 3. The selected
hypervisor, where applicable. 4. The trusted computing base. 5. The
attacker capabilities against which protection is required. 6. The
consequential operation classes being governed. 7. The actual
Das Expires 25 April 2027 [Page 122]
Internet-Draft Kernel-Hardware Execution Finality October 2026
effectuation boundaries. 8. The supported kernel interception
interfaces. 9. The supported hypervisor interception interfaces. 10.
The enforcement limitations of each selected hook. 11. The
effectuation paths available to the agent. 12. The method of
restricting unauthorized alternate paths. 13. The authenticated
execution-context binding.
14. The Candidate Act construction procedure. 15. The non-effective
staging mechanism. 16. The descriptor schema and canonicalization
algorithm. 17. The PED implementation. 18. The protected authority-
state representation. 19. The required predicate-evaluation
procedure. 20. The validation-evidence format and commitment
ordering. 21. The scoped finality capability format and lifecycle.
22. The Finality Sink's actual-operation reconstruction procedure.
23. The required protected state transitions. 24. The concurrency
semantics of authorization consumption. 25. The revocation-
generation update procedure. 26. The behavior of already queued
operations. 27. The handling of asynchronous dispatch. 28. The
recovery and rollback-protection mechanism. 29. The treatment of
device or virtual-machine migration. 30. The handling of resource
exhaustion and unavailable enforcement components. 31. The hardware
or firmware primitives used where additional protection is required.
32. The verification tests demonstrating the claimed protection
properties.
The selected implementation must provide technical detail sufficient
to carry out the features required by the applicable enforcement
point.
Merely identifying a kernel, hypervisor, eBPF program, SmartNIC, or
TEE without explaining its actual role and enforcement properties
does not establish complete enablement of the claimed function.
7.1.152. S-5.64 - Technical Effect
The representative embodiment separates artificial-intelligence
computation from protected authority to produce designated
consequential effects.
Kernel or hypervisor mechanisms may restrict direct resource access
and intercept effectcapable operations.
A PED evaluates the authorization conditions for a governed Candidate
Act and establishes the required protected validation evidence and
bounded finality authority.
A Finality Sink verifies the actual pending operation before
permitting the specified consequence.
Das Expires 25 April 2027 [Page 123]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The architecture can be implemented through operating-system
components, hypervisor services, protected firmware, dedicated
hardware, or cooperating distributed components.
Its security properties depend upon the actual trust boundaries,
protected state, interception coverage, and effectuation interfaces
of the selected implementation.
7.1.152.1. S-5.65 - Technical Summary
this implementation profile discloses a kernel- and hypervisor-
mediated artificial-intelligenceagent execution architecture
comprising an agent execution context, enforceable operation
interception, Candidate Act staging, a Protected Enforcement Domain,
protected validation evidence, scoped non-bearer finality enablement,
and a Finality Sink configured to control a designated consequential
effect.
The architecture may employ operating-system access-control
mechanisms, supported kernel hooks, Linux Security Modules, eBPF
observation or enforcement, hypervisor-controlled device interfaces,
trusted execution environments, hardware security modules,
programmable network devices, storage controllers, accelerator
interfaces, and other protected enforcement components.
The system distinguishes observation from actual effectuation control
and distinguishes initial access permission from authorization of a
particular consequential operation.
It further provides representative mechanisms for operation
correspondence, protected state consumption, authority revocation,
hardware command handling, effectuation-path completeness, and
recovery.
The embodiment does not require physical separation of all named
functional roles where the applicable enforcement points permit co-
location.
Nor does it impose the protected execution-finality sequence on other
independently architectures that expressly use different enforcement
mechanisms.
7.1.152.2. CLOUD-HOSTED, API-GATEWAY-MEDIATED, AND DISTRIBUTED
ARTIFICIAL-INTELLIGENCE-AGENT EXECUTION WITH CROSS-DOMAIN
7.1.152.3. AUTHORITY BINDING, PROTECTED CREDENTIAL USE, AND FINALITY
SINK VERIFICATION
Das Expires 25 April 2027 [Page 124]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2. Implementation Profile S-7
Source location: original disclosure pages 341-396. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.2.1. S-7.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, hardware-rooted trust, cryptographically isolated
execution, protected computing, secure key management, protected
mutable state, cryptographic attestation, anti-replay control,
rollback resistance, and enforcement of consequential operations.
More particularly, the embodiment describes a computing architecture
in which one or more artificial-intelligence agents execute within,
outside, or in cooperation with a hardwareprotected or
cryptographically isolated computing arrangement, while specified
consequential operations remain subject to independently enforceable
authorization conditions.
The architecture may employ:
(a) a Trusted Execution Environment (TEE); (b) a Hardware Security
Module (HSM);
(c) a secure enclave;
(d) a secure element;
(e) a hardware security coprocessor;
(f) a confidential-computing virtual machine;
(g) hardware-assisted memory isolation;
(h) hardware-rooted measurement or attestation;
(i) protected firmware;
(j) authenticated state storage;
(k) protected cryptographic keys;
(l) a secure execution controller;
(m) a programmable network or storage device;
Das Expires 25 April 2027 [Page 125]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(n) a secure accelerator or device partition; or
(o) combinations thereof.
The components may be colocated, distributed, physically separated,
or integrated within one protected device.
In the representative protected-finality implementation, a Candidate
Act remains noneffective until the required protected authorization
conditions are satisfied and an appropriately controlled Finality
Sink permits the specified consequential effect.
The disclosure is not limited to any particular processor
architecture, cryptographic chip, TEE implementation, HSM vendor,
confidential-computing product, or cloud provider.
7.2.2. S-7.2 - Technical Problem
Artificial-intelligence agents may process untrusted instructions,
retrieve information, generate executable code, invoke tools, operate
through privileged connectors, and request consequential changes to
external resources.
A software authorization mechanism may rely upon the integrity of a
host operating system or privileged software service.
Where the intended threat model includes compromise of that software,
ordinary software controls may not provide the required separation
between an agent's ability to request an operation and the authority
required to make the operation effective.
Hardware-supported isolation can protect certain execution and
cryptographic functions.
However, hardware isolation alone does not necessarily provide
complete operation-specific authorization.
For example:
(a) a TEE may execute an approved program but receive an unauthorized
operation request;
(b) an HSM may protect a signing key while signing arbitrary
operation data supplied by a compromised caller;
(c) remote attestation may establish selected workload measurements
without establishing authorization of a specific payment, network
request, file modification, or device command;
Das Expires 25 April 2027 [Page 126]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(d) sealed storage may protect confidentiality and integrity without
independently preventing restoration of a previously valid but stale
state;
(e) a cryptographic authorization artifact may be copied, replayed,
or redirected unless its permitted use is appropriately constrained;
(f) an authorization generated inside an enclave may be used by an
untrusted host to perform a materially different operation;
(g) a host may bypass an enclave-controlled validation interface by
accessing an alternate device, credential, storage, or network path;
(h) an authorization service and a downstream resource controller may
disagree about the current revocation or authority generation;
(i) an operation may be approved before its target resource changes;
(j) a system may lose protected state during restart or device
replacement;
(k) a hardware command may already be queued when authorization is
revoked; and
(l) an attacker may attempt rollback, replay, resource substitution,
attestation substitution, or unauthorized cryptographic signing.
this implementation profile addresses these problems through explicit
separation of protected computation, protected authority, validation
evidence, bounded finality enablement, and actual effectuation
control.
7.2.3. S-7.3 - Technical Objectives
The representative system is configured to provide:
1. Identification of an agent-associated execution context.
2. Hardware-supported or cryptographically protected authorization
functions. 3. Separation of agent-controlled computation from
protected authority state. 4. Protection of required validation
logic against unauthorized modification. 5. Protected storage or
derivation of cryptographic keys. 6. Authenticated association of
protected components with their actual execution state. 7. Staging
of governed Candidate Acts in a Non-Effective State. 8. Protected
evaluation of operation-specific authority predicates. 9. Machine-
verifiable evidence of successful validation. 10. Scoped non-bearer
finality enablement. 11. Independent verification at a controlled
Das Expires 25 April 2027 [Page 127]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Finality Sink. 12. Prevention of unauthorized capability replay or
substitution. 13. Controlled transition of protected mutable
authorization state. 14. Detection or prevention of prohibited
rollback. 15. Binding of an actual pending operation to the
authorized effectuation scope. 16. Secure handling of revocation,
restart, state recovery, and migration. 17. Support for co-located
and distributed PED/CIED/Finality Sink implementations. 18. Support
for software-only components cooperating with hardware-protected
components. 19. Explicit handling of hardware security limitations
and unsupported protection enforcement points.
Not every independently claimed alternative architecture requires all
of these functions.
The selected protected-finality enforcement point determines the
required combination.
7.2.4. PART I - PRINCIPAL ARCHITECTURE
7.2.5. S-7.4 - Principal Components
A representative system comprises the following components.
7.2.6. Component A - Computing Platform
A physical or virtualized computing platform containing one or more
processors, memory resources, storage interfaces, communication
interfaces, and effect-capable devices.
7.2.7. Component B - Agent Execution Environment
A computing context executing an artificial-intelligence agent, model
runtime, tool dispatcher, generated application, delegated worker, or
other agent-associated workload.
The Agent Execution Environment may be less trusted than the
protected enforcement components.
7.2.8. Component C - Hardware Root of Trust
A hardware-backed security foundation configured to supply one or
more protected identity, key, measurement, verification, isolation,
or state-management functions.
The available properties depend upon the actual hardware.
Das Expires 25 April 2027 [Page 128]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.9. Component D - Protected Execution Controller
A component configured to create, initialize, measure, and manage
protected execution contexts.
7.2.10. Component E - Protected Enforcement Domain
A PED providing the enforcement integrity required by the applicable
embodiment.
7.2.11. Component F - Cryptographically Isolated Enforcement Domain
A CIED configured to provide the additional cryptographic protection
required for specified authority-critical operations or state.
7.2.12. Component G - Protected Key Custody Controller
A mechanism configured to generate, store, derive, use, rotate,
disable, or destroy cryptographic key material according to specified
access and authorization rules.
7.2.13. Component H - Attestation and Measurement Controller
A mechanism configured to produce or evaluate trustworthy evidence
concerning selected protected execution or device state.
7.2.14. Component I - Candidate Act Interceptor
A component configured to identify an operation requiring protected-
finality authorization.
7.2.15. Component J - Non-Effective Operation Holder
A mechanism configured to retain a governed operation without
permitting its designated consequential effect.
7.2.16. Component K - Protected Authority-State Controller
A component configured to maintain policy, authorization, revocation,
quota, generation, consumption, or other security-critical state.
7.2.17. Component L - Protected Validation Controller
A component configured to evaluate the required authority predicates.
Das Expires 25 April 2027 [Page 129]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.18. Component M - Validation Evidence Commitment Controller
A protected mechanism configured to establish the evidence of
successful validation required by the selected finality protocol.
7.2.19. Component N - Scoped Finality Enablement Controller
A mechanism configured to create or activate a bounded non-bearer
finality capability.
7.2.20. Component O - Finality Sink
A component controlling the actual designated effectuation boundary
and performing or enforcing the required authorization verification.
7.2.21. Component P - Protected State Continuity Controller
A component configured to manage freshness, anti-replay information,
state generations, rollback detection, and recovery.
7.2.22. Component Q - Controlled Communication Interface
A mechanism configured to transport authenticated requests, evidence
references, bounded authorization, or operation representations
between cooperating protected components.
7.2.23. Component R - Recovery and Revocation Controller
A component configured to restrict or reconcile authority following
revocation, component restart, device failure, protected-state loss,
or migration.
The listed components describe logical functions and need not
correspond to separate physical devices.
7.2.24. S-7.5 - Reference Deployment
In one representative implementation:
1. An artificial-intelligence agent executes in an ordinary process,
container, or virtual machine. 2. The agent has no direct authority
to modify protected finality-enforcement state. 3. A controlled
interface captures a proposed consequential operation. 4. The
operation is held in a Non-Effective State. 5. A CIED verifies the
required authorization predicates using protected authority state. 6.
The CIED commits protected validation evidence. 7. A scoped non-
bearer finality capability is established. 8. A Finality Sink
obtains the actual pending operation. 9. The Finality Sink verifies
Das Expires 25 April 2027 [Page 130]
Internet-Draft Kernel-Hardware Execution Finality October 2026
its required binding to the authorization, evidence, and current
state. 10. The authorized operation is performed through the
controlled effectuation interface. 11. The system records or
reconciles the resulting effectuation state.
The CIED may be implemented using a TEE, HSM, secure controller, or
combination of protected hardware and software.
The Finality Sink may be physically separate from the CIED.
Alternatively, both may reside within one appropriately protected
component, provided that the required validation, evidence,
enablement, and verification functions remain implemented.
7.2.25. PART II - HARDWARE ROOT OF TRUST
7.2.26. S-7.6 - Hardware Root of Trust
A Hardware Root of Trust means one or more hardware-supported
mechanisms providing an initial basis for selected security
guarantees.
Such guarantees may concern:
(a) device identity; (b) protected key custody; (c) measured
initialization; (d) secure boot verification; (e) hardware-supported
isolation; (f) authenticated state; (g) protected counter or
generation state; (h) cryptographic operations; or (i) access to
selected protected device interfaces.
A Hardware Root of Trust does not necessarily provide all listed
properties.
Each implementation must identify the actual supported mechanisms and
the protections that follow from them.
A device capable of cryptographic signing does not automatically
provide secure execution, rollback resistance, or non-bypassable
effectuation control.
7.2.27. S-7.7 - Hardware-Rooted Identity
A protected component may possess a hardware-rooted or hardware-
associated identity.
The identity may be represented through:
x A protected private key.
Das Expires 25 April 2027 [Page 131]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | A hardware-protected credential. |
| - | --------------------------------------- |
| x | An attestation key. |
| x | A device identity certificate. |
| x | A derived device identity. |
| x | A protected device registration record. |
The identity may authenticate a particular device, module, protected
execution instance, or security domain.
An authenticated device identity is not itself authorization to
perform every operation requested by that device.
The relevant operation must satisfy the applicable protected
authority predicates.
7.2.28. S-7.8 - Secure Boot and Measured Boot
In one implementation, a computing platform performs authenticated
verification or measurement of selected firmware, bootloader,
operating-system, hypervisor, or protected execution components.
Secure boot may restrict loading of unauthorized executable
components.
Measured boot may record measurements for subsequent appraisal.
Such procedures may support an assessment of the computing platform's
state.
They do not independently establish that an AI-agent operation is
authorized.
Where a enforcement point requires runtime logic correspondence,
protected authority validation, or sinkside operation verification,
the corresponding mechanisms remain separately required.
7.2.29. PART III - TRUSTED EXECUTION ENVIRONMENTS
7.2.30. S-7.9 - TEE Execution Domain
A Trusted Execution Environment comprises a hardware-rooted or
hardware-assisted execution arrangement providing specified isolation
and protection properties.
Depending upon the selected platform, the TEE may protect:
Das Expires 25 April 2027 [Page 132]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Execution memory. 2. Selected code integrity. 3. Cryptographic
key material. 4. Protected input or output buffers. 5. Attestation
measurements. 6. Secure execution state.
7. Selected storage or sealing operations. 8. Access to protected
device or service interfaces.
The precise guarantees depend upon the TEE design and its
configuration.
A TEE does not automatically protect every peripheral, host-
controlled I/O path, untrusted service, or external resource.
7.2.31. S-7.10 - TEE-Resident PED
In one implementation, the PED executes within a TEE.
The agent operates outside the TEE.
The TEE receives a Candidate Act Descriptor through a controlled
interface.
The TEE obtains protected authority state and evaluates the required
predicates.
It commits the applicable validation evidence and establishes bounded
finality authorization.
The TEE does not release unrestricted authority to the requesting
agent.
7.2.32. S-7.10.1 - Protected executable logic
The TEE may maintain or verify a measurement associated with its
validation logic.
The measurement may be compared with an approved state or class.
The implementation must distinguish:
(a) validation of the protected enforcement program itself; and (b)
authorization of the actual operation requested through that program.
Approval of the enforcement program does not necessarily imply
approval of every request submitted to it.
Das Expires 25 April 2027 [Page 133]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.33. S-7.11 - TEE-Resident Agent
In another implementation, the AI agent itself executes within a TEE
or confidentialcomputing environment.
The TEE may protect selected agent memory, model data, or execution
state against specified software adversaries.
However, the agent's protected execution does not automatically
confer unrestricted external authority.
The system may therefore employ:
1. 2. 3. 4. 5. 6.
A separate PED. A separate CIED. A distinct protected authorization
compartment. A protected resource controller. A downstream Finality
Sink. An integrated protected controller with distinct logical
functions.
The protected agent may propose an operation while the protected
authorization service independently determines whether the operation
may be made effective.
7.2.34. S-7.12 - Compartmentalized TEE
A TEE may contain logically separated functions or protected
compartments where the selected platform supports such separation.
For example:
Compartment A: Agent computation.
Compartment B: Protected authority-state evaluation.
Compartment C: Validation evidence commitment.
Compartment D: Finality enablement.
Compartment E: Effectuation control.
The compartments may share hardware while preserving the access and
authorization restrictions required by the applicable enforcement
point.
The embodiment must specify which components can access or modify
protected authority state.
Das Expires 25 April 2027 [Page 134]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Merely using separate software modules within one enclave does not
necessarily establish independent security domains if all modules
possess unrestricted access to the same protected keys and mutable
state.
7.2.35. PART IV - HARDWARE SECURITY MODULES
7.2.36. S-7.13 - HSM-Based Protected Authority
In an HSM implementation, selected security-critical operations are
performed by a hardware-backed cryptographic or protected-state
controller.
The HSM may:
(a) maintain protected authorization keys; (b) authenticate authority
objects; (c) verify operation descriptors; (d) evaluate protected
authorization parameters; (e) maintain protected usage state; (f)
generate authenticated validation evidence; (g) establish bounded
finality authorization; or (h) control cryptographic effectuation.
These functions depend upon the programming interfaces and protected
execution capabilities of the selected HSM.
A generic HSM that exposes only an unrestricted signing operation
does not thereby implement the entire described CIED.
7.2.37. S-7.14 - Protected Key Custody
The HSM or secure controller may maintain private keys or other
secrets without exporting their raw values into agent-controlled
memory.
Possible keys include:
| x | Authority-signing keys. |
| - | -------------------------------- |
| x | Evidence-authentication keys. |
| x | Attestation keys. |
| x | State-sealing keys. |
| x | Capability-authentication keys. |
| x | Credential-use keys. |
| x | Inter-domain communication keys. |
The key policy determines which operations may be performed using
each key.
Das Expires 25 April 2027 [Page 135]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.38. S-7.14.1 - Separation of key purposes
In one implementation, keys used for evidence authentication,
capability generation, state sealing, and external credential use are
logically or cryptographically separated.
Such separation may be implemented through distinct keys, derived
subkeys, hardware key slots, or permitted-use restrictions.
The use of a signing key for one purpose must not automatically
authorize its use for unrelated operations.
7.2.39. S-7.15 - Protection Against Unrestricted Signing
An attacker may attempt to use an HSM as an unrestricted signing
oracle.
For example, the attacker may submit an unauthorized transaction
descriptor to an HSM that possesses a valid signing key.
A protected-finality HSM implementation therefore does not sign or
activate a finality authorization merely because a syntactically
valid request was received.
Instead, the HSM performs or enforces the applicable protected
authorization procedure.
The HSM may require:
1. An authenticated requesting context. 2. An accepted operation
descriptor. 3. Valid protected authority state. 4. Successful
predicate evaluation. 5. Required protected validation evidence. 6.
Permitted operation scope. 7. Freshness or nonce validity. 8.
Applicable revocation state. 9. Authorized target boundary. 10.
Protected usage-state conditions.
Only after required conditions are satisfied does the HSM establish
the corresponding bounded authorization.
7.2.40. S-7.16 - HSM-Based Cryptographic Finality Sink
A cryptographic signing interface may itself constitute a
consequential effectuation boundary.
For example, a signature may enable:
Das Expires 25 April 2027 [Page 136]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Acceptance of a financial instruction. |
| - | -------------------------------------------- |
| x | Authentication of an infrastructure command. |
| x | Approval of a software deployment. |
| x | Issuance of a privileged credential. |
| x | Activation of an authorization artifact. |
| x | Acceptance of a protected transaction. |
Where signing is the governed consequential effect, an HSM may serve
as the Finality Sink when it controls whether the signature is
generated and verifies the required operationspecific authorization
before doing so.
Where the signature merely precedes an independently controlled
downstream effect, the implementation must distinguish the signing
boundary from the later effectuation boundary.
7.2.41. PART V - PED AND CIED RELATIONSHIP
7.2.42. S-7.17 - PED as Functional Enforcement Domain
A PED comprises one or more components whose implemented protection
properties are sufficient to maintain the enforcement integrity
required by the applicable embodiment.
A PED may be implemented in protected software, firmware, hardware,
or a hybrid arrangement.
The PED designation does not require a particular cryptographic
primitive or physical device unless expressly claimed.
7.2.43. S-7.18 - CIED as Cryptographically Protected PED
A CIED is a PED providing the additional cryptographic isolation and
protected-state properties required by the relevant embodiment.
In one representative CIED implementation, protected hardware
controls:
(a) executable validation logic; (b) authorization-state integrity;
(c) protected key use; (d) authenticated validation evidence; (e)
bounded capability activation; (f) permitted protected-state
transitions; (g) applicable replay protection; and (h) applicable
state-continuity rules.
Cryptographic isolation must correspond to a defined adversary.
Das Expires 25 April 2027 [Page 137]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A CIED may be designed to resist specified unauthorized application
processes, operatingsystem processes, privileged software components,
or other adversaries according to the protection capabilities of the
selected hardware.
A universal enforcement point of resistance to all physical, side-
channel, firmware, supply-chain, or hardware-compromise attacks is
not implied.
7.2.44. S-7.19 - PED/CIED Physical Co-Location
A PED and CIED may reside in the same protected component where the
CIED supplies the required PED functions.
Similarly, one protected controller may implement validation,
evidence commitment, capability activation, and Finality Sink
verification.
Physical co-location does not eliminate the need to implement the
specific logical relationships required by the enforcement points.
For example, a enforcement point requiring evidence commitment before
scoped authorization must preserve that ordering even when one
controller performs both operations.
7.2.45. PART VI - ATTESTATION
7.2.46. S-7.20 - Protected Measurement
A Protected Measurement means a machine-readable representation
associated with one or more relevant security properties of a
computing environment.
The measurement may represent:
| x | Firmware state. |
| - | ------------------------------------- |
| x | Executable code state. |
| x | Enclave measurement. |
| x | Virtual-machine configuration. |
| x | Protected workload identity. |
| x | Security configuration. |
| x | Boot measurements. |
| x | Protected policy state. |
| x | Device firmware version. |
| x | Selected runtime security attributes. |
Das Expires 25 April 2027 [Page 138]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A measurement may be represented by a cryptographic digest,
structured record, signed report, or equivalent authenticated
measurement artifact.
The measurement must be evaluated according to its actual source and
security guarantees.
7.2.47. S-7.21 - Attestation Evidence
Attestation Evidence means information supplied to support appraisal
of a protected execution environment or device state.
An attestation record may include:
AttesterIdentity
MeasurementReference
SecurityVersion
PlatformConfiguration
ProtectedWorkloadIdentity
VerifierChallenge
FreshnessReference
AttestationSignature
EndorsementReference
The record may be specific to the selected hardware platform.
The verifier checks the authenticity and applicable acceptability of
the evidence according to a defined appraisal policy.
7.2.48. S-7.22 - Attestation Verifier
An Attestation Verifier means a component configured to evaluate
received attestation evidence against applicable reference values,
trust anchors, freshness conditions, endorsements, and appraisal
policies.
The verifier may operate:
(a) locally; (b) within a PED; (c) within a CIED; (d) through a
remote protected service; or
Das Expires 25 April 2027 [Page 139]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(e) through a cooperating set of trusted verification components.
The verifier may return an authenticated appraisal result to the
relying enforcement service.
7.2.49. S-7.23 - Attestation and Operation Authorization
Attestation may establish that a particular protected component
satisfies selected platform or workload-state conditions.
Operation authorization separately determines whether the component
is permitted to perform a specific consequential act.
A representative protected authorization procedure may require both:
1. Acceptable attestation of the protected component. 2. Successful
validation of the particular Candidate Act.
The presence of valid attestation does not automatically satisfy the
second condition.
7.2.50. S-7.24 - Attestation-to-Session Binding
An attacker may attempt to present genuine attestation evidence from
one protected environment while directing an operation to another
environment.
To address such substitution, an implementation may bind the attested
identity to an authenticated communication session.
For example:
1. The verifier issues a fresh challenge. 2. The protected
environment generates an attestation response. 3. The response
includes or authenticates a public key or channel-binding value
associated with the intended protected session. 4. The verifier
validates the attestation and associated key binding. 5. The
protected session is established using the corresponding
authenticated key. 6. The relying enforcement component associates
subsequent requests with the verified protected environment.
The mechanism must be supported by the attestation platform and the
chosen authentication protocol.
This procedure does not require a particular vendor-specific
attestation format.
Das Expires 25 April 2027 [Page 140]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.51. PART VII - PROTECTED MUTABLE STATE
7.2.52. S-7.25 - Protected Authority State
A representative CIED may maintain protected mutable state including:
1. Policy generation. 2. Revocation generation. 3. Agent or task
authority scope. 4. Evidence-commitment sequence. 5. Capability-use
state. 6. Nonce or replay state. 7. Usage quota. 8. Protected
resource-state reference. 9. Authorized Finality Sink identity. 10.
Recovery generation. 11. Device security state. 12. Required
validity conditions.
The protected state may reside in secure memory, hardware-backed
storage, authenticated persistent storage, secure registers, or
combinations thereof.
7.2.53. S-7.26 - Protected-State Integrity
An implementation must prevent unauthorized modification of security-
critical state.
Possible mechanisms include:
(a) hardware access isolation; (b) authenticated storage; (c)
cryptographic message authentication; (d) digitally signed state
records; (e) secure key custody; (f) protected memory; (g) restricted
firmware execution; and (h) authenticated state-machine replication.
The selected mechanism must be appropriate for the relevant attacker
and protected state.
Encryption alone does not necessarily protect integrity unless an
appropriate authenticated construction and validation procedure are
used.
7.2.54. S-7.27 - Protected State Transition
A protected authorization-state transition may be represented as:
CURRENT_STATE + VALIDATED_EVENT + EXPECTED_VERSION → NEXT_STATE
The transition may be performed using:
Das Expires 25 April 2027 [Page 141]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | A protected compare-and-update operation. |
| - | --------------------------------------------------- |
| x | A transactionally protected registry. |
| x | A secure hardware state machine. |
| x | A protected monotonic sequence. |
| x | A cryptographically authenticated state transition. |
| x | An atomic register operation. |
| x | An authenticated replicated state machine. |
The implementation must define the transition's atomicity,
durability, and concurrency properties required by the claimed
operation.
7.2.55. PART VIII - ROLLBACK RESISTANCE
7.2.56. S-7.28 - State Rollback Threat
A protected state record may be restored from an earlier valid
version.
Although its cryptographic integrity may remain valid, the record may
contain obsolete authorization, revocation, or capability-consumption
information.
For example, a stored record may indicate:
CapabilityStatus = UNUSED
even though a later valid state recorded:
CapabilityStatus = CONSUMED
A valid signature or authentication tag on the earlier record does
not by itself establish that the earlier record is current.
7.2.57. S-7.29 - Anti-Rollback State Anchor
A rollback-resistant implementation may maintain a protected state
anchor that identifies the latest accepted state or generation.
The anchor may comprise:
(a) a suitable hardware monotonic counter; (b) a hardware-protected
generation register; (c) a trusted external freshness service; (d) a
protected append-only state commitment; (e) an authenticated
replicated monotonic state machine;
(f) a secure nonvolatile state mechanism; or
Das Expires 25 April 2027 [Page 142]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(g) another mechanism capable of enforcing the required continuity
property.
The selected implementation must establish how the anchor itself is
protected from unauthorized rollback.
A locally sealed record without an independent freshness or
monotonicity mechanism is not necessarily rollback-resistant.
7.2.58. S-7.30 - Protected State Recovery
Upon restart, the CIED obtains its latest recoverable protected
state.
A representative recovery procedure:
1. Authenticates the recovered state. 2. Determines its state
generation. 3. Obtains the applicable protected continuity anchor.
4. Compares the recovered generation with the anchor. 5. Rejects
prohibited stale state. 6. Reconciles incomplete capability-
consumption transitions. 7. Reconciles pending or indeterminate
external operations. 8. Establishes the permitted recovered
authority state. 9. Resumes governed effectuation only when the
required consistency conditions are satisfied.
A failure to recover the required state does not automatically
authorize initialization of a fresh unrestricted authority
generation.
7.2.59. PART IX - CANDIDATE ACT STAGING
7.2.60. S-7.31 - Candidate Act Capture
An AI agent generates a proposed consequential operation.
The operation may include:
| x | Network transmission. |
| - | ---------------------------- |
| x | Protected credential use. |
| x | File modification. |
| x | Persistent database commit. |
| x | Cryptographic signing. |
| x | Payment instruction. |
| x | Cloud resource modification. |
| x | Accelerator operation. |
| x | Storage command. |
| x | Physical device actuation. |
Das Expires 25 April 2027 [Page 143]
Internet-Draft Kernel-Hardware Execution Finality October 2026
An interceptor creates a Candidate Act associated with the
authenticated originating context.
7.2.61. S-7.32 - Non-Effective Operation Holding
The system maintains the governed operation in a Non-Effective State.
Possible mechanisms include:
(a) a controlled software request buffer; (b) a protected operation
registry; (c) a withheld cryptographic key-use request; (d) an
uncommitted resource transaction; (e) a disabled output queue; (f) a
protected command descriptor; (g) a held network request; or (h) an
operation staging area controlled by the protected resource
interface.
The effectuation interface must prevent the designated consequence
while authorization remains unsatisfied.
7.2.62. S-7.33 - Candidate Act Descriptor
A representative descriptor includes:
CandidateActID = CA-0701
AgentContextID = AGENT-42
TaskID = TASK-204
OperationClass = CRYPTOGRAPHIC_SIGN
TargetResource = TRANSACTION-81
DescriptorDigest = DIGEST-0701
AuthorityGeneration = 105
RequiredSink = FS-HSM-01
CandidateStatus = STAGED
The values are illustrative.
A production descriptor defines the material operation parameters and
the canonicalization procedure used for authorization and final
effectuation.
Das Expires 25 April 2027 [Page 144]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.63. PART X - PROTECTED VALIDATION
7.2.64. S-7.34 - Protected Authorization Procedure
The CIED obtains the Candidate Act Descriptor and relevant
authenticated execution context.
The required authorization predicates may include:
1. Agent identity. 2. Task identity. 3. Delegation scope. 4.
Requested operation. 5. Target resource. 6. Transaction or output
parameters. 7. Protected policy version. 8. Revocation generation.
9. Usage quota. 10. Freshness. 11. Resource-state precondition.
12. Required attestation. 13. Approved computational-logic state.
14. Runtime behavioral condition. 15. Human authorization. 16.
Target Finality Sink identity.
The predicates are selected according to the applicable enforcement
point and policy.
7.2.65. S-7.35 - Protected Validation Evidence
Following successful validation, the CIED commits protected
validation evidence.
A representative record comprises:
EvidenceID = VE-0701
CandidateActID = CA-0701
ValidatedDescriptorDigest = DIGEST-0701
CIEDIdentity = CIED-01
PolicyGeneration = 105
ValidationResult = APPROVED
RequiredSinkID = FS-HSM-01
EvidenceGeneration = 910
ProtectedCommitment = AUTHENTICATED-STATE-REFERENCE
The record may be authenticated through a protected key or maintained
within protected mutable state.
Das Expires 25 April 2027 [Page 145]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The exact evidence format must be specified for an actual
implementation.
7.2.66. S-7.36 - Evidence Commitment Ordering
Where the applicable enforcement point requires committed validation
evidence before finality enablement, the following ordering is
maintained:
VALIDATION SUCCESS
↓
PROTECTED EVIDENCE COMMITMENT
↓
SCOPED FINALITY CAPABILITY ACTIVATION
↓
FINALITY SINK VERIFICATION
↓
EFFECTUATION
If the evidence commitment fails, the capability is not made
independently usable.
If capability activation fails after evidence commitment, the
corresponding authorization remains inactive or is reconciled
according to the defined protected-state procedure.
7.2.67. PART XI - SCOPED NON-BEARER FINALITY CAPABILITY
7.2.68. S-7.37 - Protected Finality Capability
A Scoped Non-Bearer Finality Capability represents a bounded
authority condition associated with a validated Candidate Act.
A representative record comprises:
CapabilityID = CAP-0701
CandidateActID = CA-0701
EvidenceReference = VE-0701
Das Expires 25 April 2027 [Page 146]
Internet-Draft Kernel-Hardware Execution Finality October 2026
AuthorizedDescriptorDigest = DIGEST-0701
AuthorizedSinkID = FS-HSM-01
AuthorizedOperation = CRYPTOGRAPHIC_SIGN
AuthorityGeneration = 105
UsagePolicy = SINGLE_USE
CapabilityStatus = ACTIVE
The capability may be represented through software-protected or
hardware-protected state.
7.2.69. S-7.38 - Hardware Capability Representations
A hardware implementation may employ:
(a) a protected capability register;
(b) a secure key-use authorization entry;
(c) a protected hardware latch;
(d) an operation-specific queue grant;
(e) an authenticated protected state-machine entry;
(f) an HSM-internal authorization object;
(g) a protected command permission; or
(h) a combination thereof.
The implementation must preserve the operation scope, required
validation dependencies, and usage semantics.
A hardware permission bit permitting unrestricted future operations
would not automatically satisfy a enforcement point requiring a
capability bound to one Candidate Act and one protected evidence
commitment.
7.2.70. S-7.39 - Capability Anti-Replay
Where the applicable enforcement point requires single-use
authorization, the CIED or Finality Sink maintains protected
consumption state.
Das Expires 25 April 2027 [Page 147]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A representative transition is:
UNUSED → RESERVED → CONSUMED
An attempt to consume a capability already reserved or consumed is
handled according to the applicable concurrency and recovery rules.
A single-use capability must not be reactivated merely by restoring
an earlier host snapshot or replaying an authenticated request.
7.2.71. PART XII - FINALITY SINK IMPLEMENTATION
7.2.72. S-7.40 - Hardware or Software Finality Sink
The Finality Sink controls a specified consequential operation.
Possible implementations include:
1. A protected credential-use interface. 2. An HSM signing
interface.
3. A secure network controller. 4. A SmartNIC. 5. A DPU. 6. A
storage-commit controller. 7. A DMA controller. 8. An accelerator
command controller. 9. A protected gateway. 10. A secure firmware
actuator interface. 11. A protected application resource controller.
The Finality Sink may execute within the same protected device as the
CIED or in a separate protected component.
7.2.73. S-7.41 - Independent Actual-Operation Verification
The Finality Sink obtains or reconstructs the actual pending
operation.
For cryptographic signing, the sink may verify:
| x | Actual data to be signed. |
| - | -------------------------------------------------- |
| x | Domain-separation or signature-purpose identifier. |
| x | Applicable transaction or resource identity. |
| x | Authorized operation scope. |
| x | Protected evidence reference. |
| x | Capability identity. |
| x | Current authority generation. |
| x | Current usage state. |
For network transmission, the sink may verify:
Das Expires 25 April 2027 [Page 148]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Actual transmitted payload or protected digest. |
| - | ----------------------------------------------- |
| x | Destination. |
| x | Applicable protocol. |
| x | Target interface. |
| x | Required authorization state. |
For a device command, the sink may verify:
| x | Actual command. |
| - | -------------------------------- |
| x | Target hardware device. |
| x | Command parameters. |
| x | Queue or controller identity. |
| x | Applicable authority generation. |
The verification must correspond to the actual operation controlled
by the sink.
7.2.74. S-7.42 - Remote Finality Sink
A CIED may generate protected authorization on one machine while a
Finality Sink operates on another.
The authorization communication may include:
CandidateActID
EvidenceReference
CapabilityReference
AuthorizedSinkIdentity
ActualOperationDigest
AuthorityGeneration
NonceOrSequence
AuthenticationProof
The Finality Sink verifies the applicable message authenticity,
scope, and protected state.
Where single-use consumption is required across remote components,
the implementation must specify a suitable coordination or sink-local
consumption mechanism.
Das Expires 25 April 2027 [Page 149]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A valid cryptographic signature does not alone prevent reuse where
the effectuation controller lacks appropriate replay or state-
consumption controls.
7.2.75. S-7.43 - Non-Bypassability
The intended architecture prevents the governed effect through
unauthorized alternate paths.
For example, if an HSM protects a signing key but the same private
key is also available in ordinary application memory, the HSM does
not exclusively control signing with that key.
Likewise, if a TEE authorizes network requests but an agent can
transmit equivalent requests directly through an unrestricted network
adapter, the TEE does not provide non-bypassable network finality.
The implementation must control the actual effectuation paths covered
by the enforcement point.
7.2.76. PART XIII - PROTECTED CROSS-COMMITTED EVIDENCE VARIATION
7.2.77. S-7.44 - Two Protected Validation Instances
In an additional embodiment, validation may be performed through two
protected instances or independently protected validation contexts.
A first protected instance may establish collection-time or
preparation-time evidence.
A second protected instance may establish execution-time validation.
The system may construct a cross-committed evidence representation
linking the two results.
This is an optional stronger implementation unless expressly required
by the applicable enforcement point.
7.2.78. S-7.45 - Cross-Commitment Representation
A representative cross-commitment may include:
FirstValidationEvidenceID
SecondValidationEvidenceID
CandidateActID
Das Expires 25 April 2027 [Page 150]
Internet-Draft Kernel-Hardware Execution Finality October 2026
CanonicalDescriptorDigest
FirstProtectedDomainID
SecondProtectedDomainID
PolicyGeneration
ExecutionGeneration
CrossCommitmentDigest
The cross-commitment is constructed through a specified cryptographic
encoding or authenticated state relationship.
Where the invention requires two independent protected instances,
merely executing the same validation routine twice within one
unseparated process does not necessarily satisfy that requirement.
7.2.79. S-7.46 - Sink Verification of Cross-Committed Evidence
In an embodiment requiring cross-committed evidence, the Finality
Sink verifies:
1. Valid first-instance evidence. 2. Valid second-instance
evidence. 3. Required instance-identity relationships. 4. Agreement
on material operation fields. 5. Correct cross-commitment. 6.
Applicable current authority state. 7. Valid scoped finality
authorization. 8. Actual pending operation correspondence.
Failure of a required relationship causes the consequential operation
to be withheld.
7.2.80. PART XIV - PRINCIPAL ENABLEMENT WORKFLOW
7.2.81. S-7.47 - Complete 30-Step Successful Execution Workflow
7.2.82. Step S7-01 - Hardware security initialization
The computing platform initializes the selected protected hardware or
cryptographic enforcement environment.
7.2.83. Step S7-02 - Protected component authentication
The system establishes the identity of the PED, CIED, or protected
controller according to the applicable implementation.
Das Expires 25 April 2027 [Page 151]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.84. Step S7-03 - Protected executable-state verification
Where required, the system verifies acceptable validation logic or
protected workload configuration.
7.2.85. Step S7-04 - Protected key establishment
The protected key custody mechanism initializes or obtains applicable
cryptographic keys.
7.2.86. Step S7-05 - Protected authority-state recovery
The system recovers and authenticates the required authority state.
7.2.87. Step S7-06 - State-continuity verification
Applicable rollback-resistant generations or protected freshness
references are verified.
7.2.88. Step S7-07 - Attestation
Where required, attestation evidence is generated and evaluated.
7.2.89. Step S7-08 - Secure communication establishment
The system creates the authenticated communication channels required
between enforcement components.
7.2.90. Step S7-09 - Agent execution-context registration
The agent and assigned task are associated with authenticated
execution identity and authority scope.
7.2.91. Step S7-10 - Effectuation-path verification
The controlled interfaces for designated consequential operations are
identified and configured.
7.2.92. Step S7-11 - Agent computation
The agent performs permitted internal computation.
7.2.93. Step S7-12 - Consequential operation proposal
The agent generates an operation requiring protected finality.
Das Expires 25 April 2027 [Page 152]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.94. Step S7-13 - Candidate Act capture
The operation is intercepted before its designated consequential
effect.
7.2.95. Step S7-14 - Non-effective staging
The operation is held in a controlled representation.
7.2.96. Step S7-15 - Descriptor canonicalization
The material operation parameters are represented under a defined
canonicalization profile.
7.2.97. Step S7-16 - CIED submission
The descriptor and authenticated execution context are provided to
the protected enforcement domain.
7.2.98. Step S7-17 - Protected authority-state acquisition
The CIED obtains current applicable policy, revocation, scope, and
usage state.
7.2.99. Step S7-18 - Protected predicate evaluation
The CIED evaluates all required authorization predicates.
7.2.100. Step S7-19 - Optional independent validation
Where required, a second protected validation instance evaluates its
assigned predicates.
7.2.101. Step S7-20 - Protected evidence commitment
The required validation evidence is committed.
7.2.102. Step S7-21 - Optional cross-commitment
Where required, independent evidence records are cryptographically
linked.
7.2.103. Step S7-22 - Scoped capability establishment
The CIED creates or activates bounded finality authority.
Das Expires 25 April 2027 [Page 153]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.104. Step S7-23 - Capability delivery or protected reference
activation
The authorization becomes available only to the permitted enforcement
path.
7.2.105. Step S7-24 - Actual pending operation acquisition
The Finality Sink obtains or reconstructs the operation it is about
to effectuate.
7.2.106. Step S7-25 - Evidence verification
The sink verifies the required protected validation evidence.
7.2.107. Step S7-26 - Capability and actual-operation verification
The sink verifies operation correspondence, resource scope, current
authority state, and relevant capability bindings.
7.2.108. Step S7-27 - Protected consumption transition
Where required, the sink atomically reserves or consumes the
capability.
7.2.109. Step S7-28 - Controlled effectuation
The authorized operation is performed.
7.2.110. Step S7-29 - Completion observation
The system obtains the available effectuation status.
7.2.111. Step S7-30 - Protected state reconciliation
The corresponding protected operation, consumption, and recovery
records are updated.
7.2.112. PART XV - REFERENCE ALGORITHMS
S-7.48 - Algorithm A: Protected Hardware Initialization
function InitializeProtectedAuthoritySystem(configuration):
hardware = IdentifySupportedSecurityHardware()
if not VerifyRequiredHardwareProperties(
Das Expires 25 April 2027 [Page 154]
Internet-Draft Kernel-Hardware Execution Finality October 2026
hardware, configuration.required_properties ):
return DENIED
protected_domain = InitializeProtectedDomain(hardware)
if not VerifyProtectedCodeState(protected_domain):
return DENIED keys = InitializeProtectedKeyMaterial(
protected_domain, configuration.key_policy )
state = RecoverAuthenticatedAuthorityState()
if not VerifyStateContinuity(state):
RestrictGovernedEffectuation() return RECOVERY_REQUIRED
RegisterProtectedDomainIdentity(
protected_domain, keys, state.generation )
if not VerifyRequiredEffectuationPaths():
RestrictGovernedEffectuation() return DENIED
return ACTIVE
The selected hardware platform must supply the protection mechanisms
required by the configuration.
7.2.113. S-7.49 - Algorithm B: Attestation Appraisal
function VerifyProtectedExecutionEnvironment(
attestation_evidence, expected_context, challenge ):
if not VerifyAttestationAuthenticity(attestation_evidence):
return DENIED if not VerifyAttestationFreshness(
attestation_evidence, challenge ):
return DENIED
if not VerifyExpectedMeasurements(
attestation_evidence, expected_context ):
Das Expires 25 April 2027 [Page 155]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED
if not VerifySecurityVersionRequirements(
attestation_evidence ):
return DENIED
if not VerifySessionBinding(
attestation_evidence, expected_context.session ):
return DENIED
return ACCEPTABLE_ATTESTATION
Successful attestation establishes only the properties represented
and accepted through the attestation mechanism.
It does not independently authorize a Candidate Act.
7.2.114. S-7.50 - Algorithm C: Protected CIED Validation
function ValidateCandidateInCIED(candidate_id, descriptor):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != STAGED:
return DENIED
if not VerifyAuthenticatedOriginBinding(
descriptor, record ):
return DENIED
authority = ProtectedAuthorityState.lookup(descriptor)
if not VerifyCurrentAuthorityGeneration(authority):
return DENIED if not EvaluateRequiredAuthorityPredicates(
descriptor, authority ):
CommitProtectedDenial(candidate_id) return DENIED
evidence = CommitProtectedValidationEvidence({
Das Expires 25 April 2027 [Page 156]
Internet-Draft Kernel-Hardware Execution Finality October 2026
candidate_id: candidate_id, descriptor_digest:
HashCanonical(descriptor), authority_generation:
authority.generation, evaluated_scope: authority.scope,
validation_result: APPROVED })
if evidence is invalid:
return DENIED capability = CreateScopedNonBearerFinalityAuthority({
candidate_id: candidate_id, evidence_reference: evidence.id,
descriptor_digest: HashCanonical(descriptor), authorized_sink:
descriptor.sink_id, permitted_scope: authority.scope,
authority_generation: authority.generation })
if not ActivateProtectedCapabilityAtomically(
candidate_id, evidence, capability ):
DisableCapability(capability) return DENIED
return AUTHORIZED
The evidence and capability activation sequence must preserve the
required protected ordering and recovery properties.
S-7.51 - Algorithm D: Hardware Finality Sink Verification
function VerifyAndEffectuate(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED
actual_operation = ObtainActualPendingEffectOperation(
candidate_id )
if actual_operation is unavailable:
return DENIED evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
Das Expires 25 April 2027 [Page 157]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if not VerifyEvidenceCommitment(evidence):
return DENIED if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED if not VerifyActualOperationBinding(
actual_operation, capability ):
return DENIED if not
VerifyCurrentProtectedAuthorityState(capability):
return DENIED if not VerifySinkLocalProtectedState(capability):
return DENIED if not ReserveCapabilityAtomically(capability):
return DENIED result = ExecuteThroughControlledBoundary(
actual_operation )
ReconcileProtectedOperationOutcome(
candidate_id, result )
return result
A hardware implementation may realize the same procedure through
protected state machines, firmware, registers, or controller
microcode.
S-7.52 - Algorithm E: Single-Use Capability Consumption
function ReserveCapabilityAtomically(capability):
begin protected_atomic_transaction
state = ReadProtectedConsumptionState(
capability.id )
if state != UNUSED:
abort return DENIED
if not VerifyCurrentAuthorityAndRevocation(capability):
abort return DENIED
Das Expires 25 April 2027 [Page 158]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if not VerifyRequiredStateGeneration(capability):
abort return DENIED
SetProtectedConsumptionState(
capability.id, RESERVED )
AdvanceProtectedTransitionSequence()
commit protected_atomic_transaction
return RESERVED
If the external effect is not committed atomically with this local
transition, separate dispatch and completion records are required.
7.2.115. S-7.53 - Algorithm F: Rollback-Resistant Recovery
function RecoverCIEDState():
candidate_state = LoadSealedOrAuthenticatedState()
if not VerifyStateAuthentication(candidate_state):
return RECOVERY_REQUIRED
anchor = ReadProtectedContinuityAnchor()
if anchor is unavailable:
return RECOVERY_REQUIRED
if not VerifyAcceptedGeneration(
candidate_state.generation, anchor ):
return ROLLBACK_DETECTED
unresolved = RecoverOutstandingOperations(
candidate_state )
for each operation in unresolved:
ApplyProtectedReconciliation(operation)
if not VerifyCurrentEffectuationRestrictions():
Das Expires 25 April 2027 [Page 159]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return RESTRICTED
return ACTIVE
The protected continuity anchor must itself resist the rollback
attacker assumed by the deployment.
7.2.116. S-7.54 - Algorithm G: Secure Capability Revocation
function RevokeProtectedAuthority(
affected_context, restricted_scope ):
generation = AdvanceProtectedAuthorityGeneration(
affected_context )
affected_capabilities = FindAffectedCapabilities(
affected_context,
restricted_scope )
for each capability in affected_capabilities:
ApplyRevocationState(capability, generation)
affected_sinks = ResolveAffectedFinalitySinks(
restricted_scope )
for each sink in affected_sinks:
DistributeProtectedRevocationGeneration(
sink, generation )
if not VerifyRequiredSinkConvergence(affected_sinks):
ApplyCompensatingEffectuationRestrictions()
return EvaluateRevocationCompletion()
Where outstanding hardware commands are included in the restriction,
the implementation must also address their queue and execution state.
Das Expires 25 April 2027 [Page 160]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.117. S-7.55 - Algorithm H: Protected Key-Use Finality
function PerformProtectedSigning(candidate_id):
operation = ObtainActualPendingSigningOperation(
candidate_id )
if operation is unavailable:
return DENIED if not VerifyRequiredFinalityAuthorization(
candidate_id, operation ):
return DENIED
if not VerifySigningKeyUsePolicy(operation):
return DENIED if not ReserveSingleUseAuthorization(
candidate_id ):
return DENIED
signature = HSM.SignAuthorizedOperation(
operation.key_reference, CanonicalSigningPayload(operation) )
RecordProtectedSigningOutcome(
candidate_id, signature )
return signature
The HSM interface must prevent unauthorized callers from invoking an
equivalent unrestricted signing path using the same protected key.
7.2.118. PART XVI - WORKED TECHNICAL EXAMPLES
S-7.56 - Example A: HSM-Protected Supplier Payment Authorization
The following is a hypothetical implementation example.
An AI agent prepares a payment instruction involving a supplier
account.
The agent does not possess the bank's protected signing key.
Das Expires 25 April 2027 [Page 161]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The proposed payment is staged before a signature capable of
authorizing settlement is generated.
A Candidate Act Descriptor identifies:
| x | The payment instruction. |
| - | -------------------------------------------- |
| x | The beneficiary. |
| x | The payment amount. |
| x | The payer. |
| x | The required authorization context. |
| x | The relevant transaction identifier. |
| x | The intended cryptographic signing boundary. |
The CIED validates the required authority and transaction predicates.
Protected validation evidence is committed.
A scoped single-use capability is established for the specific
payment instruction.
The HSM signing interface acts as the Finality Sink for the signing
effect.
It obtains the actual canonical signing payload.
It verifies correspondence with the authorized transaction.
It checks current protected authority and capability-consumption
state.
If verification succeeds, the HSM signs the permitted instruction.
A later request to sign a modified beneficiary, amount, or
transaction is not authorized merely because the requesting agent
previously obtained approval for a different payment.
The actual settlement of funds may occur at a distinct downstream
financial boundary governed by a separate system.
7.2.119. S-7.57 - Example B: TEE-Protected Network Egress
An AI agent operates in an ordinary container.
A TEE implements protected authorization functions.
The container requests transmission of enterprise information.
Das Expires 25 April 2027 [Page 162]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The host-side egress interface stages the request.
The TEE validates the required recipient, data scope, task authority,
and policy generation.
Protected validation evidence is committed.
The TEE establishes a bounded capability.
A protected network controller obtains the actual pending
transmission.
The controller verifies the required capability and operation
correspondence.
If all mandatory conditions succeed, the controller permits
transmission.
If an untrusted host can instead transmit the same information
through another uncontrolled interface, the intended non-
bypassability property is not established.
S-7.58 - Example C: Attested Workload Requesting an Unauthorized
Operation
An AI-agent workload executes inside a TEE having acceptable
attestation evidence.
The protected workload requests deletion of a restricted enterprise
database.
The attestation verifier confirms that the relevant protected
workload measurement is acceptable.
However, the protected authorization service evaluates the actual
deletion request separately.
The requested database deletion exceeds the assigned task authority.
The PED or CIED denies authorization.
No scoped finality capability is activated.
The resource Finality Sink does not execute the deletion.
This example illustrates that valid hardware attestation does not
independently authorize every operation of the attested workload.
Das Expires 25 April 2027 [Page 163]
Internet-Draft Kernel-Hardware Execution Finality October 2026
S-7.59 - Example D: Rollback of Consumed Authorization
A protected authorization capability is initially marked UNUSED.
The Finality Sink consumes the capability.
The protected consumption state advances to CONSUMED.
An attacker later restores a previously authenticated storage record
indicating UNUSED.
The protected recovery procedure compares the restored generation
against an independently protected continuity anchor.
The old state is rejected when it violates the current protected
generation.
The consumed capability is not reactivated.
If the selected hardware provides authenticated sealing but no
effective freshness or monotonicity mechanism, the implementation
cannot enforcement point the same rollback-resistance property
without an additional suitable control.
S-7.60 - Example E: Hardware Controller and Outstanding Queue
Operations
An agent submits commands to a hardware accelerator through a
protected controller.
The controller validates authorization before admission of governed
commands.
A restrictive authority update is issued while earlier commands
remain queued.
The controller advances the applicable authority generation.
Commands not yet admitted under the new generation are rejected where
prohibited.
Previously admitted commands are classified according to their actual
execution and cancellation status.
Where the claimed restriction requires preventing the effect of
outstanding commands, the controller applies supported queue fencing,
quiescence, or cancellation mechanisms.
Das Expires 25 April 2027 [Page 164]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The system does not equate updating one authorization register with
proof that every previously admitted hardware command has ceased to
be effect-capable.
S-7.61 - Example F: Cross-Domain Protected Validation
An enterprise agent executes in Cloud Domain A.
A protected authorization service operates in Domain B.
The Finality Sink operates in Domain C.
The agent requests a consequential resource modification.
The operation is staged and represented by a canonical descriptor.
The CIED in Domain B validates the required predicates and commits
protected evidence.
A scoped capability is established for the designated Finality Sink
in Domain C.
The sink authenticates the relevant authorization information.
The sink reconstructs the actual pending operation and checks its
permitted resource scope.
A capability bound to a different sink or resource does not authorize
the current operation.
The system performs the effect only after the required validation
succeeds.
7.2.120. PART XVII - FAILURE AND ADVERSARIAL CASES
7.2.121. S-7.62 - Representative Failure Conditions
7.2.122. F1 - Unauthorized TEE Call
An agent submits a request to an otherwise valid TEE that exceeds its
authorized task.
The protected validation logic denies the request.
7.2.123. F2 - HSM Signing Oracle
An attacker attempts to sign arbitrary data using a protected key.
Das Expires 25 April 2027 [Page 165]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The protected key-use policy requires the applicable operation-
specific authorization.
7.2.124. F3 - Attestation Replay
An attacker replays previously valid attestation evidence.
The verifier checks the applicable challenge, freshness, and session
binding.
7.2.125. F4 - Attestation Substitution
An attacker attempts to substitute evidence from a different
protected environment.
The verifier checks the required execution identity and session
association.
7.2.126. F5 - Compromised Host Software
An attacker controls untrusted host software.
The architecture preserves only those security properties actually
enforced beyond the compromised host's authority.
7.2.127. F6 - Protected-State Tampering
An attacker modifies an ordinary storage copy of authority state.
Authenticated state verification detects unauthorized modification.
7.2.128. F7 - Sealed-State Rollback
An attacker restores an earlier valid sealed state.
A protected continuity mechanism rejects prohibited stale
generations.
7.2.129. F8 - Capability Replay
A consumed capability is presented again.
Protected usage state rejects the replay.
7.2.130. F9 - Capability Substitution
A capability bound to one operation is applied to another.
Das Expires 25 April 2027 [Page 166]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The sink detects a descriptor or scope mismatch.
7.2.131. F10 - Sink Substitution
A capability authorized for one Finality Sink is presented to
another.
The sink identity binding is checked.
7.2.132. F11 - Resource Substitution
The resource differs from the resource previously authorized.
The Finality Sink rejects unauthorized correspondence.
7.2.133. F12 - Signing-Payload Substitution
The actual data to be signed differs from the authorized payload.
The signing interface withholds the signature.
7.2.134. F13 - Key Extraction Attempt
An attacker attempts to export a protected private key.
The hardware key policy prevents export where the selected component
supports and enforces that protection.
7.2.135. F14 - Key-Use Policy Bypass
An alternate API permits unrestricted use of the same signing key.
The configuration fails the asserted exclusive protected key-use
condition until the bypass is eliminated.
7.2.136. F15 - CIED Restart
The protected enforcement component restarts.
Required authorization and consumption state are recovered and
verified before protected effectuation resumes.
7.2.137. F16 - HSM Replacement
A failed HSM is replaced.
Das Expires 25 April 2027 [Page 167]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Key custody, authority generation, protected state, and pending
operation status are transferred or re-established through an
authorized recovery process.
7.2.138. F17 - Protected Counter Exhaustion
A protected monotonic counter reaches a platform limit or becomes
unavailable.
The system applies a defined restrictive or recovery procedure rather
than resetting protected authority continuity without authorization.
7.2.139. F18 - Protected Storage Unavailable
A required protected-state record cannot be retrieved.
The governed operation remains withheld until required state validity
is established.
7.2.140. F19 - Expired Attestation
An attestation result is no longer acceptable under the applicable
freshness policy.
The required protected access or operation is denied or revalidated.
7.2.141. F20 - Security-Version Rollback
A protected component reports a security version below an accepted
minimum.
The verifier applies the configured security-version policy.
7.2.142. F21 - Concurrent Capability Use
Two workers attempt to consume one single-use capability.
An atomic protected transition prevents unauthorized double
consumption.
7.2.143. F22 - Remote State Inconsistency
A CIED and Finality Sink have incompatible revocation generations.
The applicable consistency or fail-closed policy prevents
unauthorized effectuation.
Das Expires 25 April 2027 [Page 168]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.144. F23 - Network Partition
A protected authorization component becomes unreachable.
The system uses only an expressly permitted bounded offline authority
mechanism or withholds the governed operation.
7.2.145. F24 - Hardware Queue Already Admitted
A previously authorized command remains pending after revocation.
The implementation applies the required queue-state or continuation
rule.
7.2.146. F25 - Side-Channel Exposure
A hardware execution environment may remain vulnerable to selected
side channels.
The specification does not assert universal side-channel resistance
without platform-specific supporting protection.
7.2.147. F26 - Physical Hardware Attack
An attacker obtains physical access to a protected device.
The applicable security guarantee depends on the tamper-resistance,
physical protection, key handling, and recovery properties actually
supplied.
7.2.148. F27 - Firmware Compromise
A firmware component required for protected enforcement is
compromised.
The design requires an appropriate measurement, update, isolation, or
recovery mechanism if resistance to that compromise is claimed.
7.2.149. F28 - Alternative Effectuation Path
An agent bypasses the protected controller through an unrestricted
device or service interface.
The architecture must restrict or mediate that path to satisfy the
claimed non-bypassability property.
Das Expires 25 April 2027 [Page 169]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.150. F29 - Incomplete Protected Transition
A crash occurs between evidence commitment and capability activation.
The recovery procedure ensures that authorization state does not
become independently usable without the required committed evidence
and valid activation.
7.2.151. F30 - Indeterminate External Completion
An authorized external operation may have occurred, but its
acknowledgment is lost.
The system preserves the unresolved outcome and applies the defined
reconciliation procedure.
7.2.152. F31 - Incorrect Canonicalization
The CIED and sink interpret the same structured request differently.
The operation is rejected or processed under a common specified
canonicalization profile.
7.2.153. F32 - Unauthorized Protected Policy Update
An attacker attempts to modify the CIED's protected authorization
policy.
The update interface requires the applicable authenticated policy-
change authority.
7.2.154. PART XVIII - HARDWARE, SOFTWARE, AND DISTRIBUTED VARIATIONS
7.2.155. S-7.63 - TEE-Based PED with Software Finality Sink
A TEE implements protected validation and authority-state handling.
A host-side protected service acts as the Finality Sink.
This arrangement is suitable where the host-side sink remains
trustworthy under the defined threat model.
It does not automatically provide non-bypassable enforcement against
an attacker possessing unrestricted control over that host service.
Das Expires 25 April 2027 [Page 170]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| S-7.64 - TEE-Based PED with Hardware Finality Sink A TEE establishes protected validation evidence and bounded authorization. A SmartNIC, storage controller, cryptographic module, accelerator controller, or other protected device acts as the Finality Sink. The effectuation controller independently verifies the required authorization before performing the governed operation. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-7.65 - HSM-Resident PED and Signing Sink An HSM performs protected authorization evaluation, evidence handling, bounded finality authorization, and signing-effect verification within one secure module. The logical functions remain distinguishable even though the same hardware device performs them. The implementation must provide the required state and authorization functionality rather than merely exposing an unrestricted cryptographic signing API. |
| S-7.66 - Secure Element Implementation A secure element may maintain selected protected keys, counters, and operation-specific state. A host processor submits Candidate Acts through a controlled interface. The secure element may perform protected validation or bounded authorization functions supported by its actual hardware and firmware. A separate controlled interface may serve as the Finality Sink. |
7.2.156. S-7.67 - Confidential Virtual Machine Implementation
An agent executes within a confidential virtual machine.
The system may use hardware-protected workload identity or
attestation.
A separate protected authorization component evaluates consequential
operations.
The actual resource effectuation boundary remains governed by the
applicable Finality Sink.
Confidential execution does not automatically authorize all
operations generated by the confidential workload.
7.2.157. S-7.68 - SmartNIC/DPU CIED Implementation
A programmable network device contains a protected authorization or
enforcement domain.
The device may maintain protected state, verify authorization
artifacts, and control selected network transmissions.
A network Finality Sink may be implemented by the same protected
device.
Where the enforcement point requires application-level operation
verification, the device must obtain the material application fields
through an appropriate trusted representation.
7.2.158. S-7.69 - Secure Accelerator Implementation
An accelerator controller may maintain protected operation context,
authority generation, and command-admission state.
Agent-generated accelerator or device operations are admitted only
according to the required protected authorization.
Where queue execution and completion are governed effects, the
controller may additionally verify or fence outstanding commands.
Das Expires 25 April 2027 [Page 171]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The actual properties depend on the accelerator's supported hardware
primitives.
7.2.159. S-7.70 - Distributed CIED Implementation
Two or more protected components may cooperate to perform validation,
protected state maintenance, evidence commitment, or bounded
authorization.
The distributed arrangement may use authenticated messages, protected
key custody, stategeneration checks, and appropriately consistent
state replication.
A distributed CIED must satisfy the cryptographic isolation and
state-protection properties required by the selected enforcement
point.
Cryptographically authenticated communication alone is insufficient
to establish the complete distributed enforcement relationship.
7.2.160. S-7.71 - Single-Chip Integrated Finality Implementation
A processor, secure controller, system-on-chip, or equivalent
integrated device may implement Candidate Act staging, protected
validation, evidence commitment, capability activation, and
effectuation control.
The implementation may use separate hardware state machines,
protected firmware regions, secure registers, and internal
authorization interfaces.
A single physical chip may therefore implement multiple logical
security roles.
The enforcement point-required ordering and protected verification
relationships remain applicable.
7.2.161. S-7.72 - Cross-Device Protected Authorization
A CIED may authorize operations on external effect-capable devices.
A protected interface conveys the required operation scope and
authorization state to the target device.
The target Finality Sink verifies the applicable authorization before
the governed effect.
Das Expires 25 April 2027 [Page 172]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where revocation or state-consumption must remain consistent across
devices, the corresponding coordination mechanism must be specified.
7.2.162. PART XIX - REPRESENTATIVE TECHNICAL DATA STRUCTURES
7.2.163. S-7.73 - ProtectedExecutionContextRecord
Fields may include:
1. ProtectedDomainID. 2. HardwareIdentityReference. 3.
WorkloadMeasurement. 4. AgentContextID. 5. TaskID. 6.
ExecutionGeneration. 7. AuthorityGeneration.
8. SecurityVersion. 9. ProtectionProfile. 10. LifecycleState.
7.2.164. S-7.74 - AttestationEvidenceRecord
Fields may include:
1. AttesterIdentity. 2. MeasurementReference. 3.
SecurityConfiguration. 4. SecurityVersion. 5. VerifierChallenge. 6.
SessionBinding. 7. AttestationSignature. 8. EndorsementReference.
9. EvidenceGeneration. 10. ValidityReference.
7.2.165. S-7.75 - ProtectedAuthorityStateRecord
Fields may include:
1. AuthorityStateID. 2. AuthorizedAgentOrTask. 3.
PermittedOperationScope. 4. CurrentPolicyGeneration. 5.
CurrentRevocationGeneration. 6. ProtectedQuotaState. 7.
NonceOrReplayState. 8. ProtectedTransitionSequence. 9.
ContinuityAnchorReference. 10. LastAuthenticatedUpdate.
7.2.166. S-7.76 - CandidateActRecord
Fields may include:
1. CandidateActID. 2. 3. 4. 5. 6.
AgentContextID. TaskID. OperationClass. TargetResource.
CanonicalDescriptorDigest.
7. AuthorityGeneration. 8. IntendedSinkID. 9. CandidateStatus. 10.
StagingReference.
Das Expires 25 April 2027 [Page 173]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.2.167. S-7.77 - ProtectedValidationEvidenceRecord
Fields may include:
1. EvidenceID. 2. CandidateActID. 3. DescriptorDigest. 4.
CIEDIdentity. 5. PolicyGeneration. 6. EvaluatedAuthorityScope. 7.
ValidationResult. 8. EvidenceCommitment. 9. EvidenceGeneration. 10.
RequiredSinkID.
7.2.168. S-7.78 - ScopedFinalityCapabilityRecord
Fields may include:
1. CapabilityID. 2. CandidateActID. 3.
ValidationEvidenceReference. 4. DescriptorDigest. 5.
AuthorizedOperationScope. 6. AuthorizedResource. 7.
AuthorizedSinkID. 8. AuthorityGeneration. 9. UsagePolicy. 10.
ExpiryCondition. 11. CapabilityStatus. 12.
ProtectedConsumptionReference.
7.2.169. S-7.79 - SinkLocalProtectedStateRecord
Fields may include:
1. SinkID. 2. CapabilityID. 3. CandidateActID.
4. ExpectedOperationDigest. 5. AuthorityGeneration. 6.
RevocationGeneration. 7. ConsumptionState. 8. DispatchStatus. 9.
ExternalOperationReference. 10. CompletionStatus. 11.
StateGeneration.
7.2.170. S-7.80 - ProtectedStateContinuityRecord
Fields may include:
1. ContinuityAnchorID. 2. LatestAcceptedGeneration. 3.
ProtectedStateDigest. 4. AuthorityGeneration. 5.
RevocationGeneration. 6. ConsumptionStateRoot. 7.
RecoveryGeneration. 8. AnchorAuthenticationReference. 9.
RecoveryStatus.
7.2.171. S-7.81 - CrossCommitmentRecord
Fields may include:
Das Expires 25 April 2027 [Page 174]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. FirstEvidenceID. 2. SecondEvidenceID. 3.
FirstProtectedDomainID. 4. SecondProtectedDomainID. 5.
CandidateActID. 6. CanonicalDescriptorDigest. 7. PolicyGeneration.
8. CrossCommitmentDigest. 9. VerificationStatus.
7.2.172. S-7.82 - ProtectedHardwareOperationRecord
Fields may include:
1. 2. 3.
OperationID. OriginatingExecutionContext. HardwareDeviceID.
4. QueueID. 5. CommandClass. 6. CommandDescriptorDigest. 7.
AuthorityGeneration. 8. CapabilityReference. 9. AdmissionState. 10.
ExecutionState. 11. CompletionState. 12. FencingGeneration.
These records may be implemented through secure memory, authenticated
persistent storage, protected registers, secure-device firmware, HSM-
internal objects, or cooperating protected software and hardware
components.
7.2.173. PART XX - implementer ENGINEERING VERIFICATION
7.2.174. S-7.83 - Representative Verification Tests
The following are proposed tests rather than representations of
experiments already performed.
7.2.175. Test Condition
T1 Valid protected authorization T2 Missing required evidence T3
Invalid capability T4 Replayed single-use capability T5 Modified
operation descriptor T6 HSM arbitrary signing attempt T7 Attestation
evidence replay T8 Attestation environment substitution T9
Unsupported workload measurement Required access denied T10 Revoked
policy generation T11 Sealed-state rollback T12 Concurrent
consumption T13 HSM restart T14 Protected key-use bypass T15 TEE
unavailable T16 Finality Sink unavailable T17 Host compromise attempt
T18 Protected policy tampering T19 Hardware queue revocation T20
Incomplete evidence commitment
7.2.176. Expected technical behavior
Governed effect permitted Effect withheld Effect withheld Rejected
Mismatch detected Restricted by operation policy Freshness check
fails Binding mismatch detected
Das Expires 25 April 2027 [Page 175]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Invalid authorization withheld Stale generation detected where
protection is claimed Usage constraint enforced Required state
recovered or effect withheld Prohibited alternate key use prevented
No unauthorized fallback No uncontrolled effectuation Defined
hardware-backed protections tested Unauthorized change rejected
Required fencing behavior established Capability not usable
T21 Remote CIED/Sink mismatch T22 Resource-state change T23 Cross-
commitment mismatch T24 Attestation session-key substitution T25
Protected-counter or anchor
unavailable T26 Device replacement T27 External result indeterminate
T28 Unsupported claimed hardware
property T29 Key export attempt T30 Cryptographic-purpose
substitution T31 Stale capability after snapshot
restoration T32 Multiple protected components
inconsistent
Operation denied Required current-state check enforced Operation
denied when mandatory Binding verification rejects substitution
Restrictive recovery behavior Protected authority continuity re-
established or restricted Reconciliation state preserved
Implementation not represented as satisfying property Protected key
policy enforced Unauthorized key use denied Replay or generation
check rejects
Required consistency restriction applied
Tests should be adapted to the selected hardware platform, security-
module interface, firmware, operating system, and effectuation
controller.
A reproducible implementation should specify the expected state
transitions, protected records, injected failures, and measurable
pass/fail conditions.
7.2.177. PART XXI - Enforcement-Point Mapping and Technical
Correspondence
7.2.178. S-7.84 - Enforcement-Point Mapping and Technical
Correspondence
this implementation profile provides representative technical
disclosure potentially relevant to enforcement points concerning:
Das Expires 25 April 2027 [Page 176]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) protected AI-agent execution; (b) PED and CIED implementations;
(c) hardware-rooted authorization; (d) protected validation evidence;
(e) scoped non-bearer finality capabilities; (f) protected
credential-use finality; (g) cryptographic signing finality;
(h) attested execution;
(i) protected mutable authority state;
(j) rollback-resistant authorization;
(k) sink-local capability consumption;
(l) hardware command authorization;
(m) distributed protected enforcement;
(n) co-located authorization and effectuation control;
(o) hardware-assisted sandboxing;
(p) protected cross-committed validation evidence;
(q) device authority generations;
(r) credential and key separation; and
(s) software-hardware hybrid implementations.
The embodiment may support portions of the protected-finality,
credential-finality, hardware enforcement, distributed revocation,
and cross-device authority-control enforcement point families.
The exact written-description and enablement support for each
finalized enforcement point must be established limitation by
limitation.
7.2.179. PART XXII - implementer IMPLEMENTATION REQUIREMENTS
7.2.180. S-7.85 - Implementation Checklist
For a selected hardware or cryptographically isolated implementation,
a implementer identifies:
1. The protected hardware platform. 2. The processor, controller,
and firmware architecture. 3. The precise supported isolation
guarantees. 4. The attacker capabilities included in the threat
model. 5. The trusted computing base. 6. The protected executable
Das Expires 25 April 2027 [Page 177]
Internet-Draft Kernel-Hardware Execution Finality October 2026
measurement mechanism. 7. The hardware identity and key custody
mechanisms. 8. The selected attestation format and verifier
procedure. 9. The attestation freshness and session-binding
procedure. 10. The authority-state storage format. 11. The
protected state-update algorithm. 12. The protected state-continuity
mechanism.
13. The rollback-resistance anchor, where required. 14. The
Candidate Act interception point. 15. The non-effective staging
mechanism. 16. The canonical descriptor schema. 17. The protected
validation algorithm. 18. The required authorization predicates. 19.
The evidence-commitment representation. 20. The evidence/capability
ordering semantics. 21. The scoped finality capability
representation. 22. The permitted cryptographic key uses. 23. The
Finality Sink interface. 24. The actual pending operation
reconstruction procedure. 25. The sink-local protected state. 26.
The atomic authorization-consumption mechanism. 27. The
authorization revocation mechanism. 28. The recovery and restart
procedure. 29. The handling of incomplete state transitions. 30.
The treatment of outstanding hardware commands. 31. The behavior of
the system under network partition or remote authorization loss. 32.
The prevention of alternate effectuation paths. 33. The protection
against unrestricted cryptographic signing or credential use. 34.
The hardware limitations relevant to side-channel, firmware, and
physical attacks. 35. The platform-specific test procedures
establishing the claimed properties.
An actual implementation must supply the specific hardware
instructions, device interfaces, protected firmware functions,
cryptographic encodings, storage guarantees, and statetransition
mechanisms needed to implement the features.
The generic identification of a TEE, HSM, secure enclave, or
protected processor is not sufficient when the enforcement point
requires security properties that the selected platform does not
automatically provide.
7.2.181. S-7.86 - Technical Effect
The representative embodiment separates artificial-intelligence
computation from protected authority to produce consequential
effects.
Hardware-rooted or cryptographically isolated components may protect
validation logic, authority state, cryptographic keys, evidence
commitments, and bounded finality authorization.
Das Expires 25 April 2027 [Page 178]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A Finality Sink verifies the actual pending consequential operation
before permitting the governed effect.
The architecture distinguishes:
1. Protected execution. 2. Hardware attestation.
3. Operation authorization. 4. Protected evidence commitment. 5.
Bounded capability activation. 6. Actual-operation verification. 7.
Effectuation. 8. Protected state consumption. 9. Revocation and
recovery.
These functions may be implemented within one secure device or across
cooperating protected components.
The security guarantees depend on the actual hardware properties,
protected execution boundaries, state-continuity mechanisms, and
effectuation paths of the selected implementation.
7.2.182. S-7.87 - Technical Summary
this implementation profile discloses a hardware-rooted and
cryptographically isolated artificial-intelligence-agent execution
architecture comprising an agent execution context, a protected
hardware or cryptographic enforcement arrangement, Candidate Act
staging, protected authorization-state evaluation, validation-
evidence commitment, scoped non-bearer finality enablement, and a
Finality Sink controlling a specified consequential effect.
The architecture may employ TEEs, HSMs, secure enclaves, secure
elements, hardwareprotected keys, authenticated storage, protected
state generations, remote attestation, protected firmware, dedicated
controllers, network devices, accelerator interfaces, or combinations
thereof.
A protected workload or attested execution environment does not
independently establish authorization of every consequential
operation it proposes.
The CIED or other applicable protected enforcement component
evaluates the required operation-specific predicates.
The Finality Sink verifies the actual pending operation and required
protected authorization before permitting effectuation.
Protected state-continuity mechanisms may prevent stale
authorization, prohibited rollback, or repeated capability
consumption according to the selected implementation.
Das Expires 25 April 2027 [Page 179]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The PED, CIED, validation controller, capability controller, and
Finality Sink may be physically separated or integrated within one
protected device where the required logical and security
relationships are maintained.
The embodiment provides representative software, firmware, hardware,
and distributed implementation species without requiring every
separately claimed alternative security architecture to employ the
complete protected-finality sequence.
7.2.182.1. SMARTNIC-, DPU-, GPU-, ACCELERATOR-, AND HARDWARE-SOFTWARE-
HYBRID ARTIFICIAL-INTELLIGENCE-AGENT SANDBOX WITH PROTECTED
7.2.182.2. DEVICE AUTHORITY, DMA AND MEMORY ISOLATION, HARDWARE COMMAND
FINALITY, CROSS-DEVICE EPOCH FENCING, AND VERIFIED RESOURCE
REASSIGNMENT
7.3. Implementation Profile S-8
Source location: original disclosure pages 397-460. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.3.1. S-8.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, computer architecture, processor and accelerator isolation,
programmable network devices, direct memory access, input/output
memory management, protected hardware command admission, hardware-
enforced authorization, device-state management, resource ownership,
memory sanitization, and cross-device execution control.
More particularly, the embodiment describes a computing architecture
in which one or more artificial-intelligence agents execute on
general-purpose processors, graphics processing units, AI
accelerators, specialized processing devices, or combinations
thereof, while selected consequential operations remain subject to
enforceable hardware, firmware, software, or hybrid controls.
The system may employ:
(a) a Smart Network Interface Card (SmartNIC); (b) a Data Processing
Unit (DPU); (c) a Graphics Processing Unit (GPU); (d) an AI inference
or training accelerator; (e) a Field-Programmable Gate Array (FPGA);
(f) an Application-Specific Integrated Circuit (ASIC); (g) a Network
Processing Unit (NPU); (h) a Tensor Processing Unit or equivalent
matrix-processing accelerator;
Das Expires 25 April 2027 [Page 180]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(i) an Input/Output Memory Management Unit (IOMMU);
(j) one or more Direct Memory Access (DMA) engines;
(k) protected processor memory;
(l) device-local memory;
(m) hardware command queues;
(n) protected device registers;
(o) secure firmware;
(p) hardware-backed authorization state;
(q) a Protected Enforcement Domain (PED);
(r) a Cryptographically Isolated Enforcement Domain (CIED);
(s) one or more Finality Sinks; or
(t) combinations thereof.
The disclosure is independent of a particular processor manufacturer,
accelerator architecture, GPU programming interface, network
protocol, virtualization provider, firmware vendor, or device-
security product.
The selected implementation must, however, provide the actual memory,
command, device, and enforcement properties required by the
applicable enforcement point.
7.3.2. S-8.2 - Technical Problem
Artificial-intelligence agents may generate operations that are
ultimately carried out through hardware components rather than
exclusively through ordinary software interfaces.
Such operations may include:
1. GPU kernel execution. 2. AI inference execution. 3. Hardware
command submission. 4. DMA reads and writes. 5. Network packet
transmission. 6. Remote direct memory access. 7. Persistent storage
commands. 8. Device memory modification. 9. Accelerator-to-
accelerator transfer. 10. Model-output transfer. 11. Cryptographic
device operations. 12. Physical actuator commands.
Das Expires 25 April 2027 [Page 181]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A software permission check may occur before a command reaches the
hardware.
However, the eventual hardware effect may occur later, after the
command has been admitted to a queue or after the applicable
authorization state has changed.
For example:
(a) an agent may submit a GPU operation that is authorized when
admitted but later executes after the relevant authority has been
revoked;
(b) a kernel-mediated restriction may deny new commands while
previously submitted DMA operations remain capable of modifying
memory;
(c) a SmartNIC may transmit packets previously admitted to its
hardware queue after a software security service has changed its
policy;
(d) an IOMMU may restrict selected device memory accesses without
verifying the business or task authority associated with a permitted
DMA transfer;
(e) an accelerator may retain confidential information in device-
local memory after a software execution context is destroyed;
(f) a GPU context may be reassigned to another tenant before all
relevant commands and memory accesses from the previous tenant have
completed;
(g) a device may maintain stale address translations after software
updates a memory-access policy;
(h) a peer-to-peer device path may bypass a host software gateway;
(i) firmware may control a hardware queue without independently
verifying the operationspecific authorization required by the
corresponding enforcement point;
(j) one device may acknowledge an authority update while another
device continues operating under an earlier generation;
(k) a hardware completion signal may indicate command admission or
local processing rather than completion of the externally
consequential effect; and
Das Expires 25 April 2027 [Page 182]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(l) an untrusted agent may attempt to exploit differences between
software-visible descriptors and the commands actually executed by a
hardware controller.
Accordingly, hardware isolation, software authorization, device
command admission, device execution, and external effectuation
represent distinguishable technical functions.
this implementation profile addresses these distinctions through
protected device authority, controlled command representation,
actual-operation verification, generation-aware resource admission,
in-flight command handling, and hardware-software state
reconciliation.
7.3.3. S-8.3 - Technical Objectives
The representative system seeks to provide:
1. Hardware-assisted isolation of agent-associated execution and
resources. 2. Separation of ordinary accelerator computation from
authority to produce designated consequential effects. 3. Protected
association of operations with agent, task, device, and execution
identities. 4. Controlled admission of commands to effect-capable
hardware. 5. Non-effective staging of governed hardware operations.
6. Protected validation of operation-specific authorization
conditions. 7. Protected validation-evidence commitment. 8. Scoped
non-bearer finality enablement. 9. Finality Sink verification of the
actual pending device operation. 10. Protected hardware authority-
generation management. 11. Restrictions on stale or unauthorized
device commands. 12. Control of DMA memory-access scopes. 13.
Cross-device enforcement coordination. 14. Treatment of outstanding,
queued, and partially executed commands. 15. Safe reassignment of
device resources between execution contexts or tenants. 16. Defined
device memory-sanitization and verification procedures. 17. Recovery
from device resets, firmware restarts, queue failures, and incomplete
operations. 18. Support for hardware-only, software-only control
components, and hybrid implementations.
Not all independently claimed alternatives require the complete
protected-finality sequence.
In particular, enforcement points directed to memory sanitization,
static DMA confinement, native resource isolation, or hardware
recovery may operate through their own mechanisms without necessarily
requiring a Candidate Act receipt or scoped finality capability.
7.3.4. PART I - GENERAL HARDWARE-SOFTWARE ARCHITECTURE
Das Expires 25 April 2027 [Page 183]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.5. S-8.4 - Principal Components
A representative system comprises the following functional
components.
7.3.6. Component A - Host Computing Platform
A computing environment comprising one or more general-purpose
processors, memories, system interconnects, and device interfaces.
7.3.7. Component B - Agent Execution Runtime
An execution environment running one or more AI agents, model-serving
components, tool dispatchers, or delegated computational workers.
7.3.8. Component C - Device and Resource Manager
A component configured to allocate, configure, assign, revoke, or
recover hardware resources associated with agent workloads.
7.3.9. Component D - Hardware Isolation Controller
A mechanism configured to restrict access between selected execution
contexts, memory regions, devices, or tenants.
7.3.10. Component E - IOMMU or Equivalent Memory-Access Controller
A mechanism configured to enforce supported device-address
translation and memory-access restrictions.
7.3.11. Component F - DMA Operation Controller
A component configured to manage selected device-initiated memory
transfers.
7.3.12. Component G - Accelerator Execution Controller
A component configured to receive, schedule, or execute computation
on a GPU, AI accelerator, NPU, FPGA, ASIC, or equivalent device.
7.3.13. Component H - SmartNIC/DPU Controller
A programmable network or infrastructure processing component capable
of mediating selected communication, storage, DMA, or device
operations.
Das Expires 25 April 2027 [Page 184]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.14. Component I - Hardware Command Interceptor
A mechanism configured to identify governed device operations before
their designated consequential effectuation boundary.
7.3.15. Component J - Non-Effective Command Holder
A mechanism configured to stage governed commands while preventing
the specified effect.
7.3.16. Component K - Protected Enforcement Domain
A PED configured to evaluate required authorization conditions and
maintain or access relevant protected authority state.
7.3.17. Component L - Cryptographically Isolated Enforcement Domain
An optional CIED configured to provide stronger cryptographic
isolation and protected-state guarantees.
7.3.18. Component M - Protected Evidence Controller
A mechanism configured to commit the validation evidence required by
the selected protected-finality protocol.
7.3.19. Component N - Scoped Finality Enablement Controller
A protected mechanism configured to establish bounded authorization
for a validated consequential operation.
7.3.20. Component O - Hardware or Software Finality Sink
An enforcement component controlling the selected device admission,
hardware execution, memory transfer, network transmission, resource
commitment, or other governed effect.
7.3.21. Component P - Device Authority-Generation Controller
A component configured to maintain authorization generations
associated with selected devices, queues, execution contexts, and
resources.
7.3.22. Component Q - Command Queue and Completion Controller
A mechanism configured to maintain queue admission, command
execution, cancellation, retirement, and completion state.
Das Expires 25 April 2027 [Page 185]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.23. Component R - Hardware Fencing Controller
A mechanism configured to prevent prohibited operations associated
with a superseded authority or ownership generation.
7.3.24. Component S - Device Memory Ownership Controller
A component configured to track protected memory ownership across
agents, execution contexts, workloads, or tenants.
7.3.25. Component T - Memory Sanitization Controller
A mechanism configured to perform or enforce a required memory-
clearing, cryptographic erasure, or equivalent sanitization
procedure.
7.3.26. Component U - Device Recovery and Reconciliation Controller
A component configured to recover protected state and reconcile
outstanding operations after reset, restart, or device failure.
The components may reside in one system-on-chip, multiple processors,
multiple peripheral devices, host software, protected firmware,
dedicated security hardware, or cooperating distributed devices.
7.3.27. S-8.5 - Reference Deployment
In one representative implementation:
1. An AI agent executes within a process, container, virtual
machine, or accelerator runtime.
2. The agent generates a command requiring a consequential
operation. 3. A host or device interface captures the operation
before its governed effect. 4. The operation is associated with an
authenticated agent and device execution context. 5. A controlled
command representation is staged in a Non-Effective State. 6. A PED
evaluates the applicable authorization conditions. 7. Protected
validation evidence is committed. 8. A scoped non-bearer capability
is established. 9. A hardware or firmware Finality Sink obtains the
actual pending command. 10. The sink verifies the required evidence,
capability, authority generation, device scope, and command
correspondence. 11. An applicable protected hardware state
transition permits the authorized operation. 12. The device performs
the consequential operation. 13. Completion and unresolved operation
states are reconciled.
Das Expires 25 April 2027 [Page 186]
Internet-Draft Kernel-Hardware Execution Finality October 2026
For certain effect classes, the hardware command-admission point and
the eventual effectuation point are different.
The implementation identifies the controlled effect associated with
each Finality Sink.
7.3.28. PART II - HARDWARE ISOLATION DEFINITIONS
7.3.29. S-8.6 - Hardware-Isolated Execution Environment
A Hardware-Isolated Execution Environment means an execution or
resource context separated from other contexts through one or more
hardware-enforced mechanisms.
Isolation may comprise:
(a) processor privilege separation; (b) memory protection; (c)
hardware virtualization; (d) device memory partitioning; (e)
protected execution regions; (f) controlled device access; (g) IOMMU
restrictions; (h) protected command scheduling; (i) secure processor
partitions; or (j) combinations thereof.
The term does not imply that every implementation provides
cryptographic isolation.
The particular isolation properties must be identified.
7.3.30. S-8.7 - Accelerator Execution Domain
An Accelerator Execution Domain means a machine-identifiable
execution or resource context associated with an accelerator.
The context may comprise:
| x | Device execution queues. |
| - | ---------------------------------- |
| x | Processor or compute units. |
| x | Device-local memory allocations. |
| x | Virtual address spaces. |
| x | Command contexts. |
| x | Device register state. |
| x | Scheduler state. |
| x | Tenant associations. |
| x | Security or authority generations. |
| x | Protected device metadata. |
Das Expires 25 April 2027 [Page 187]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The domain may correspond to a complete physical device, a
virtualized accelerator, a supported partition, a process-associated
device context, or another controlled resource subdivision.
The existence of separate scheduling contexts does not automatically
establish confidentiality or integrity isolation between tenants.
7.3.31. S-8.8 - Device Authority Domain
A Device Authority Domain means a protected or otherwise enforceable
association between an execution context and the permitted operations
or resources of one or more hardware devices.
A representative authority domain may identify:
DeviceAuthorityDomainID
AgentContextID
TaskID
DeviceID
ExecutionGeneration
AuthorityGeneration
PermittedCommandClasses
PermittedMemoryRegions
PermittedEffectuationInterfaces
RevocationState
The authority domain may be enforced through protected software,
firmware, hardware registers, IOMMU state, device command validation,
or combinations thereof.
7.3.32. PART III - GPU AND AI ACCELERATOR EXECUTION
7.3.33. S-8.9 - GPU Execution Context
A GPU Execution Context means a logical or hardware-supported context
associated with execution of commands on a graphics or compute
accelerator.
A context may include:
Das Expires 25 April 2027 [Page 188]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Command streams. 2. Kernel execution parameters. 3. Device
memory mappings. 4. Allocated memory buffers. 5. Device-side
scheduling state. 6. Context identifiers. 7. Synchronization
objects. 8. Completion events. 9. Relevant execution generations.
A GPU context may execute under a general-purpose host process or an
accelerator virtualization environment.
The security properties of a context depend upon the underlying
hardware and driver implementation.
7.3.34. S-8.10 - AI Accelerator Sandbox
An AI Accelerator Sandbox means an accelerator execution arrangement
in which one or more resources, commands, memory regions, device
interfaces, or consequential operations are restricted according to
applicable technical controls.
Such restrictions may be implemented through:
(a) protected command submission; (b) device context isolation; (c)
device memory protection; (d) runtime permission checks; (e) driver-
controlled resource mapping; (f) device partitioning; (g) firmware-
enforced queue restrictions;
(h) protected DMA address mappings; or
(i) external effectuation mediation.
The sandbox may be managed by host software, firmware, hardware, or a
combination thereof.
A scheduling partition is not necessarily equivalent to a security-
isolated hardware partition.
7.3.35. S-8.11 - Agent-Originated Accelerator Operation
An AI agent may generate an operation requesting:
Das Expires 25 April 2027 [Page 189]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Model inference. |
| - | --------------------------------- |
| x | Model fine-tuning. |
| x | Retrieval processing. |
| x | Tensor computation. |
| x | Accelerator memory transfer. |
| x | Device buffer export. |
| x | Peer-to-peer transfer. |
| x | Kernel execution. |
| x | Output publication. |
| x | Persistent checkpoint generation. |
The operation may be represented by a command buffer, runtime API
invocation, command queue entry, driver request, or another device-
specific structure.
Where the operation represents a governed consequential effect, the
system captures or controls it according to the corresponding
effectuation policy.
7.3.36. S-8.12 - Computation Versus Consequential Output
An accelerator may produce a computational result without that result
immediately being released to an external recipient.
For example, a GPU may compute a model output into a protected or
restricted buffer.
The result may remain non-effective with respect to external
disclosure while it is held inside that buffer.
A separate Finality Sink may control:
(a) copying the result into an untrusted host memory region; (b)
transferring the result to a remote device; (c) publishing the result
through a network interface; (d) committing the result to persistent
storage; (e) displaying or rendering the result; (f) providing the
result to an external service; or (g) another specified consequential
release.
The implementation must identify which effect is controlled.
Authorization of computation admission does not automatically
establish authorization of all later output releases.
Das Expires 25 April 2027 [Page 190]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.37. PART IV - GPU COMMAND SUBMISSION AND FINALITY
7.3.38. S-8.13 - Hardware Command Descriptor
A Hardware Command Descriptor means a machine-readable representation
of an operation proposed for execution by a hardware device.
A representative descriptor may include:
HardwareCommandID
DeviceID
ExecutionContextID
QueueID
CommandClass
OperationParameters
InputBufferReferences
OutputBufferReferences
MemoryAccessScope
AuthorityGeneration
ResourceOwnershipGeneration
RequiredFinalitySinkID
CommandDigest
The descriptor may be represented through a protected software
object, driver command, firmware structure, device queue entry, or
hardware register set.
7.3.39. S-8.14 - Command Admission Boundary
A Command Admission Boundary means the point at which a hardware
command is accepted into a device-controlled execution queue or
another scheduled execution structure.
A device may admit commands before performing them.
Das Expires 25 April 2027 [Page 191]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where command admission is the governed consequential effect, the
Finality Sink may enforce authorization at admission.
Where the governed effect is later execution, data transfer, or
physical output, additional execution-time or output-time controls
may be required.
7.3.40. S-8.15 - Hardware Execution Boundary
A Hardware Execution Boundary means the point at which a queued
command begins or continues an operation capable of producing the
designated hardware consequence.
An execution boundary may be implemented through:
1. A command processor. 2. A protected scheduler. 3. A device
execution controller. 4. A firmware admission state machine. 5. A
hardware command-enable register. 6. A queue authorization
predicate. 7. An equivalent enforceable device mechanism.
The exact boundary depends on the hardware.
7.3.41. S-8.16 - Device Command Finality Sink
A Device Command Finality Sink means a hardware, firmware, or
effectively controlling software-hardware component configured to
prevent a specified command effect unless the required authorization
conditions are satisfied.
In one implementation, the Finality Sink verifies:
(a) the actual command descriptor; (b) the permitted device identity;
(c) the authorized execution context; (d) the applicable authority
generation; (e) the protected validation evidence; (f) the scoped
capability; (g) the current resource ownership; (h) any required
memory access scope; and (i) sink-local protected usage state.
The exact verification fields depend upon the enforcement point.
7.3.42. PART V - SMARTNIC AND DPU IMPLEMENTATION
7.3.43. S-8.17 - SmartNIC/DPU Enforcement Environment
A SmartNIC or DPU may provide programmable computation and networking
or infrastructure-control functions independently of ordinary host
application code.
Depending on the device, the protected component may control:
Das Expires 25 April 2027 [Page 192]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Network packet forwarding. |
| - | --------------------------------- |
| x | Network connection admission. |
| x | Selected packet-processing rules. |
| x | DMA operations. |
| x | Storage-related data movement. |
| x | Virtual-function assignment. |
| x | Device queues. |
| x | Workload-associated network flows. |
| - | ---------------------------------- |
| x | Protected authorization state. |
The device may contain general-purpose processing cores, specialized
packet processors, firmware, hardware tables, or programmable logic.
The particular implementation must identify which functions are
actually enforceable.
7.3.44. S-8.18 - SmartNIC-Based Agent Egress Finality
In one representative implementation, an AI-agent workload generates
a network operation.
A protected egress controller receives the pending operation through
a controlled path.
The PED validates the required authorization conditions.
Protected validation evidence and scoped finality authority are
established.
A SmartNIC-based Finality Sink verifies the required authorization
before the governed transmission.
The device may maintain protected association among:
(a) the agent execution context; (b) the network flow or request; (c)
the authorized destination; (d) the relevant payload or protected
operation descriptor; (e) the authority generation; and (f) the
corresponding finality capability.
7.3.45. S-8.18.1 - Network visibility limitation
A SmartNIC may not independently observe the full application
semantics of an encrypted or otherwise transformed request.
Das Expires 25 April 2027 [Page 193]
Internet-Draft Kernel-Hardware Execution Finality October 2026
If authorization requires application-layer fields, the system must
provide an appropriately trusted representation of those fields or
perform the relevant verification at another controlled application
boundary.
Packet filtering alone does not establish authorization of arbitrary
application transactions.
7.3.46. S-8.19 - DPU-Based Resource Control
A DPU may control selected network, storage, virtualization, or
device-management operations.
A protected DPU service may maintain authority-generation state and
enforce selected restrictions independently of guest application
code.
In a representative variation, the DPU:
1. Receives a protected workload identity association. 2. Receives
or obtains current authority state. 3. Captures a proposed device or
network operation. 4. Verifies required authorization. 5. Checks
device or queue state. 6. Applies a protected state transition. 7.
Permits the governed operation. 8. Records the resulting completion
or error status.
The actual device interface must support the operation-control
function being claimed.
7.3.47. PART VI - IOMMU AND DMA ISOLATION
7.3.48. S-8.20 - Direct Memory Access
Direct Memory Access means a mechanism through which a device or DMA-
capable controller accesses memory without requiring a general-
purpose processor to execute an ordinary load or store instruction
for each transferred unit.
DMA may be used by network devices, storage controllers,
accelerators, graphics devices, or other peripherals.
DMA may comprise reads, writes, or transfers between authorized
address spaces and devices.
A DMA request may create a consequential effect by reading protected
data, modifying memory, transmitting data, or making data accessible
to another component.
Das Expires 25 April 2027 [Page 194]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.49. S-8.21 - IOMMU Enforcement Domain
An IOMMU Enforcement Domain means a set of applicable device-to-
memory translation and protection rules enforced by an IOMMU or
equivalent device-memory access-control mechanism.
A representative domain may identify:
IOMMUDomainID
DeviceRequesterID
ApplicableAddressSpaceID
PermittedMemoryMappings
AccessPermissions
MappingGeneration
AssignedExecutionContext
DeviceOwnershipGeneration
The domain may restrict which memory regions a device can read or
write.
The isolation properties depend upon the selected hardware,
interconnect, translation configuration, and device behavior.
7.3.50. S-8.22 - DMA Permission Versus Operation Authorization
An IOMMU may allow a DMA write to a particular physical memory
region.
Such permission does not necessarily establish that the corresponding
AI-agent operation is authorized for its task.
Conversely, protected authorization of an agent operation does not
automatically configure the correct DMA address mappings.
Accordingly, a hybrid implementation may require both:
1. An appropriate device memory-access permission. 2. The
applicable operation-specific authorization condition.
The two mechanisms may cooperate while remaining logically distinct.
Das Expires 25 April 2027 [Page 195]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.51. S-8.23 - DMA Effectuation Boundary
A DMA Effectuation Boundary means a control point at which a device-
initiated memory access may be admitted, restricted, or performed.
Depending upon the device architecture, the boundary may involve:
(a) an IOMMU translation check;
(b) a device DMA descriptor admission point;
(c) a protected device command processor;
(d) a memory-controller authorization mechanism;
(e) a protected DMA submission interface; or
(f) another technically controlled path.
An IOMMU cannot be assumed to inspect arbitrary application-level
operation intent.
If an applicable enforcement point requires purpose- or transaction-
specific authorization, another protected component may supply or
verify the relevant semantic binding.
7.3.52. S-8.24 - DMA Mapping Lifetime
An authorized DMA mapping may remain usable after the software
process that created it has terminated.
Therefore, the resource manager must distinguish:
(a) process termination; (b) DMA descriptor cancellation; (c) device
command completion; (d) mapping revocation; (e) translation
invalidation; (f) in-flight memory-access completion; and (g) memory
reassignment.
The implementation must establish the necessary ordering for the
claimed protection.
7.3.53. S-8.25 - Translation Invalidation
When a DMA mapping is changed or revoked, one or more device or IOMMU
translation caches may require invalidation according to the selected
platform.
The relevant implementation may require:
Das Expires 25 April 2027 [Page 196]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Updating the mapping.
2. Issuing the appropriate invalidation operation. 3. Obtaining
completion acknowledgment. 4. Restricting new requests using the old
mapping. 5. Accounting for previously accepted or in-flight memory
requests. 6. Establishing the required safe-to-reassign condition.
Where Address Translation Services, process-associated address
spaces, or similar hardware features are used, the implementation
must account for their applicable caching and invalidation semantics.
An invalidation acknowledgment must not be treated as proof that
unrelated in-flight device operations have completed unless the
hardware actually guarantees that relationship.
7.3.54. PART VII - CROSS-DEVICE MEMORY ACCESS
7.3.55. S-8.26 - Peer-to-Peer Device Transfer
Two or more hardware devices may communicate or transfer data through
a peer-to-peer path.
Such transfers may occur without ordinary host application software
inspecting every transferred byte.
The architecture may govern:
(a) accelerator-to-accelerator transfer; (b) accelerator-to-network
transfer; (c) network-to-accelerator transfer; (d) accelerator-to-
storage transfer; (e) storage-to-network transfer; or (f) another
permitted device-to-device data path.
The actual protection depends upon the hardware topology and memory-
isolation mechanisms.
7.3.56. S-8.27 - Peer-to-Peer Effectuation Control
Where a peer-to-peer path can produce a governed consequential
effect, the enforcement architecture must control or restrict that
path.
For example, a GPU may contain confidential output data that is
transferred to a network device without first being copied into
ordinary host application memory.
An implementation claiming protected output-release finality must
ensure that the peer-topeer transfer cannot bypass the relevant
authorization.
Das Expires 25 April 2027 [Page 197]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Possible mechanisms include:
1. Protected device memory-access permissions. 2. Controlled DMA
mappings. 3. Protected transfer descriptors. 4. Secure device
command admission. 5. A device-level Finality Sink. 6. A protected
resource controller coordinating the participating devices. 7.
Another technically effective restriction.
The exact implementation depends on the available device and
interconnect controls.
7.3.57. PART VIII - PROTECTED HARDWARE AUTHORITY GENERATIONS
7.3.58. S-8.28 - Hardware Authority Generation
A Hardware Authority Generation means a machine-identifiable version
or epoch associated with permitted operations of a device, command
queue, execution context, or hardware resource.
A representative record comprises:
HardwareAuthorityGeneration = 620
AgentContextID = AGENT-42
DeviceID = GPU-02
ExecutionContextID = EXEC-17
PermittedCommandClasses = CLASS-A
ResourceOwnershipGeneration = 91
RevocationGeneration = 44
These values are illustrative.
The generation may be maintained in protected software, firmware,
hardware registers, secure controller state, or an authenticated
distributed record.
7.3.59. S-8.29 - Generation-Bound Device Command
A hardware command may be associated with the authority generation
under which it was admitted.
The command descriptor may contain or reference:
Das Expires 25 April 2027 [Page 198]
Internet-Draft Kernel-Hardware Execution Finality October 2026
CommandID
DeviceID
QueueID
ExecutionContextID
CommandDigest
AuthorityGeneration
ResourceOwnershipGeneration
PermittedEffectScope
The device controller may compare the command's generation with its
protected current state at the applicable enforcement point.
Where required, commands carrying unacceptable generations are
withheld or rejected.
7.3.60. S-8.30 - Authority Generation Transition
An authority transition may occur when:
1. A task is revoked. 2. A workload loses permission. 3. A device
is reassigned. 4. A tenant's authority is reduced. 5. A policy is
updated. 6. A security event occurs. 7. A device enters recovery.
8. A protected queue is reset. 9. A resource ownership generation
changes. 10. An authorization capability is consumed.
A representative transition is:
GENERATION 620 → GENERATION 621
The transition may invalidate or constrain future operations
associated with generation 620 according to the applicable policy.
Previously admitted operations require separate treatment if they
remain capable of producing prohibited effects.
7.3.61. PART IX - HARDWARE QUEUE FENCING
7.3.62. S-8.31 - Hardware Queue State
A device command queue may contain operations in several states.
Das Expires 25 April 2027 [Page 199]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A representative state machine comprises:
CREATED → STAGED → AUTHORIZED → ADMITTED → SCHEDULED → EXECUTING →
COMPLETED
Alternative states may include:
DENIED
CANCELED
ABORTED
FAULTED
INDETERMINATE
RECONCILIATION_REQUIRED
The definitions of admission, execution, and completion depend on the
device.
A queue completion record may represent local device completion
without necessarily confirming a remote service or external resource
effect.
7.3.63. S-8.32 - Hardware Fencing
Hardware Fencing means a technical restriction preventing specified
commands, memory accesses, resource mutations, or other operations
from proceeding under an unacceptable authority or ownership
generation.
Fencing may be implemented through:
(a) queue admission restrictions;
(b) protected scheduler state;
(c) command cancellation;
(d) device reset;
(e) controlled queue drain;
(f) IOMMU mapping revocation;
(g) memory access restriction;
Das Expires 25 April 2027 [Page 200]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(h) firmware-controlled execution disablement;
(i) protected hardware registers; or
(j) a combination thereof.
The selected mechanism must actually affect the operations covered by
the claimed restriction.
7.3.64. S-8.33 - Admission Fence
An Admission Fence prevents new prohibited commands from entering a
specified queue or execution domain.
An admission fence may be established by:
1. Disabling an entry point. 2. Updating protected queue
authorization state. 3. Rejecting commands from stale generations.
4. Restricting a command-submission interface. 5. Applying an
appropriate device permission transition.
An admission fence does not automatically stop commands that have
already been admitted.
7.3.65. S-8.34 - Execution Fence
An Execution Fence prevents designated commands from beginning or
continuing execution according to the hardware's supported control
mechanisms.
Possible implementation actions include:
(a) canceling not-yet-executing commands; (b) suspending a supported
execution queue;
(c) preventing scheduling under a stale generation;
(d) invoking supported preemption;
(e) resetting an affected execution context; or
(f) applying another device-specific control.
Some devices or command classes may not support safe interruption
after execution begins.
The implementation must identify those limitations.
Das Expires 25 April 2027 [Page 201]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.66. S-8.35 - Completion Watermark
A Completion Watermark means a machine-verifiable representation of
the extent to which commands or operations within a defined sequence
have reached a specified completion or retirement state.
A watermark may contain:
DeviceID
QueueID
ExecutionGeneration
LastSubmittedSequence
LastAdmittedSequence
LastCompletedSequence
LastRetiredSequence
WatermarkValidity
The semantics of each sequence must be defined.
A completion watermark for one queue does not automatically prove
completion of commands executing through unrelated queues.
7.3.67. S-8.36 - Quiescence
Hardware Quiescence means a state in which a specified device, queue,
resource context, or operation class has no outstanding operations
capable of violating the designated safety condition.
1. 2. 3. 4. 5. 6.
Quiescence may require:
Prevention of new command admission. Completion or cancellation of
admitted commands. Resolution of in-flight memory accesses.
Completion of required translation invalidations. Confirmation of
applicable hardware state. Restriction of alternate command paths.
Quiescence must be defined relative to the relevant operations and
resources.
Das Expires 25 April 2027 [Page 202]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A device being idle according to one performance counter does not
automatically establish security-relevant quiescence.
7.3.68. PART X - PROTECTED COMMAND FINALITY
7.3.69. S-8.37 - Candidate Hardware Act
A Candidate Hardware Act means a proposed device operation whose
designated consequential effect remains subject to a governed
authorization procedure.
The Candidate Hardware Act may comprise:
| x | DMA transfer. |
| - | -------------------------- |
| x | Network transmission. |
| x | Accelerator command. |
| x | Storage command. |
| x | Device memory export. |
| x | Protected signing request. |
| x | Hardware actuation. |
| x | Peripheral command. |
| x | Cross-device transfer. |
The operation may be staged as a command descriptor, hardware queue
entry, controlled firmware request, or protected resource
transaction.
7.3.70. S-8.38 - Hardware Non-Effective State
A Hardware Non-Effective State means a condition in which the command
may have been generated or staged but has not yet produced the
specific governed hardware effect.
Representative implementations include:
(a) an unadmitted command descriptor; (b) a disabled hardware queue
entry;
(c) a protected pending-command buffer;
(d) a firmware-held command;
(e) a DMA descriptor that has not been activated;
(f) a withheld network packet or flow operation; or
(g) a command gated by protected hardware permission.
Das Expires 25 April 2027 [Page 203]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The system must prevent the governed effect while the required
authorization remains absent.
7.3.71. S-8.39 - Hardware PED Validation
The PED evaluates the required operation-specific predicates.
Depending upon the command class, such predicates may include:
1. Agent identity. 2. Task identity. 3. Device identity. 4.
Command class. 5. Actual command parameters. 6. Memory region. 7.
Authorized DMA direction. 8. Device ownership generation. 9.
Authority generation. 10. Queue identity. 11. Device security
state. 12. Resource-state precondition. 13. Revocation state. 14.
Required attestation. 15. Protected usage limit. 16. Required
Finality Sink.
7.3.72. S-8.40 - Hardware Protected Validation Evidence
Following successful validation, the PED may commit an authenticated
record comprising:
EvidenceID = VE-HW-0801
CandidateActID = CA-HW-0801
CommandDigest = DIGEST-HW-0801
DeviceID = DPU-02
AuthorityGeneration = 620
ResourceOwnershipGeneration = 91
ValidationResult = APPROVED
RequiredSink = FS-HW-02
EvidenceGeneration = 940
The evidence may be stored in protected software, secure controller
memory, a hardwarebacked registry, or another suitable protected
representation.
7.3.73. S-8.41 - Hardware Scoped Finality Capability
The bounded capability may be represented through:
Das Expires 25 April 2027 [Page 204]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. A protected hardware permission entry. 2. A secure authorization
register. 3. A command-specific latch. 4. An authenticated
capability object. 5. A protected queue-admission entry. 6. A
secure firmware state-machine reference. 7. A protected key-use
condition. 8. A combination thereof.
The authorization is bounded to the operation and context required by
the applicable enforcement point.
A generic device-enable bit does not necessarily satisfy a
enforcement point requiring a one-time capability bound to committed
validation evidence and the actual command descriptor.
7.3.74. S-8.42 - Hardware Finality Sink Verification
The hardware or firmware Finality Sink obtains the actual pending
command.
It may verify:
(a) the actual command descriptor; (b) the target device and
resource; (c) the authorized operation class; (d) the protected
validation evidence; (e) the scoped finality capability;
(f) the authority generation;
(g) the resource ownership generation;
(h) the permitted memory scope;
(i) applicable revocation state;
(j) the required sink identity; and
(k) sink-local protected consumption state.
Upon successful verification, the sink permits the governed operation
according to the applicable command-state transition.
7.3.75. PART XI - MEMORY OWNERSHIP AND TENANT ISOLATION
7.3.76. S-8.43 - Accelerator Memory Ownership
An accelerator memory allocation may be associated with a particular
workload, agent, execution context, or tenant.
A representative ownership record includes:
Das Expires 25 April 2027 [Page 205]
Internet-Draft Kernel-Hardware Execution Finality October 2026
MemoryAllocationID
DeviceID
OwnerTenantID
OwnerExecutionContextID
OwnershipGeneration
PhysicalOrDeviceMemoryRange
PermittedAccessClasses
MappingReferences
ActiveCommandReferences
SanitizationStatus
The ownership record may be maintained by a protected device manager,
firmware component, hypervisor, or another enforcement component.
7.3.77. S-8.44 - Memory Ownership Transition
A memory ownership transition occurs when a resource previously
associated with one execution context becomes available to another.
The transition may involve:
1. Revocation of prior authority. 2. Restriction of new accesses.
3. Completion or cancellation of outstanding operations. 4.
Invalidation of relevant mappings. 5. Sanitization of residual data.
6. Verification of the required sanitization result. 7. Assignment
of a new ownership generation. 8. Release to the new owner.
The ordering is important because clearing memory before all previous
DMA writes have completed may permit stale data to be written again
after the clearing procedure.
7.3.78. S-8.45 - Residual Accelerator Memory
Residual Accelerator Memory means data or state associated with a
previous workload that remains in a device or related memory resource
after the workload has ceased active execution.
Such residual state may include:
Das Expires 25 April 2027 [Page 206]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Device-local memory buffers. |
| - | ---------------------------------------------------- |
| x | Allocator-managed memory pages. |
| x | Model intermediate results. |
| x | Temporary computation buffers. |
| x | Cached model data. |
| x | Device-accessible host buffers. |
| x | Context metadata. |
| x | Certain firmware-maintained or device-managed state. |
The actual residual-data surfaces depend upon the selected hardware.
An implementation must identify which surfaces are subject to its
sanitization guarantee.
7.3.79. PART XII - VERIFIED MEMORY SANITIZATION
7.3.80. S-8.46 - Memory Sanitization Controller
A Memory Sanitization Controller means a component configured to
ensure that selected data or state associated with a previous
execution context is no longer accessible to a subsequent
unauthorized context according to the applicable protection
requirement.
Sanitization may comprise:
(a) overwriting selected memory; (b) zeroing; (c) secure deletion of
accessible copies; (d) protected memory reinitialization; (e)
cryptographic erasure through destruction of appropriate data-
encryption keys;
(f) device reset where supported and sufficient; or
(g) another verified sanitization mechanism.
The selected procedure must address the relevant data residency and
hardware behavior.
7.3.81. S-8.47 - Sanitization Preconditions
Before memory sanitization and reassignment, the system may require:
1. Prior owner revocation. 2. Restriction of new command
submission. 3. Queue admission fencing. 4. Completion or
cancellation of outstanding device commands. 5. Completion of
relevant DMA operations. 6. Revocation of applicable device
mappings. 7. Completion of required translation invalidations. 8.
Das Expires 25 April 2027 [Page 207]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Confirmation that the prior owner cannot reestablish access. 9.
Identification of the memory range to be sanitized. 10. Verification
that the sanitization mechanism can reach the required memory region.
The necessary conditions vary with the device.
7.3.82. S-8.48 - Sanitization Procedure
A representative procedure is:
Step M1: Identify the resource to be reassigned.
Step M2: Obtain its current ownership generation.
Step M3: Mark the resource as REASSIGNMENT_PENDING.
Step M4: Prevent new operations by the previous owner.
Step M5: Fence the associated command queues.
Step M6: Drain, cancel, or otherwise resolve relevant outstanding
commands.
Step M7: Restrict previous device and host mappings.
Step M8: Complete applicable translation invalidation.
Step M9: Verify the required quiescence condition.
Step M10: Sanitize the specified memory or protected resource state.
Step M11: Obtain evidence of sanitization completion.
Step M12: Verify that the sanitization applies to the required memory
extent.
Step M13: Advance the ownership generation.
Step M14: Establish the new owner's access mappings.
Step M15: Release the resource to the new owner.
A new owner is not granted access merely because an operating-system
allocator has changed the logical owner label.
Das Expires 25 April 2027 [Page 208]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.83. S-8.49 - Sanitization Verification
A sanitization procedure may verify:
| x | The identity of the sanitized allocation. |
| - | ----------------------------------------------------------------------- |
| x | The covered memory range. |
| x | The actual completed operation. |
| x | The absence of outstanding prior-owner writes within the claimed scope. |
| x | The applicable translation-invalidation state. |
| x | The accepted ownership generation. |
| x | The completion status of the selected sanitization mechanism. |
Where readback is used, the implementation must account for the
reliability and scope of that readback.
A successful zero read from one interface does not automatically
prove that all hidden caches, remapped pages, device-managed copies,
or inaccessible memory structures have been sanitized.
The supported sanitization guarantee must correspond to the actual
hardware coverage.
7.3.84. S-8.50 - Cryptographic Erasure Variation
A memory resource may be protected through encryption under a key
specific to an execution context, tenant, allocation, or generation.
Where the selected hardware provides the necessary cryptographic and
key-isolation properties, destroying or making unavailable the
relevant encryption key may render covered residual ciphertext
inaccessible.
The implementation must verify that:
1. All data covered by the claimed erasure guarantee was encrypted
under the relevant key. 2. The key is not recoverable through an
unauthorized copy. 3. Reused or cached key material is appropriately
cleared or invalidated. 4. The key is not shared with data that must
remain accessible. 5. The replacement owner cannot recover the old
key. 6. The cryptographic implementation satisfies the required
security properties.
Cryptographic erasure does not automatically sanitize unencrypted
copies outside the protected encryption domain.
7.3.85. PART XIII - CROSS-DEVICE REVOCATION
Das Expires 25 April 2027 [Page 209]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.86. S-8.51 - Multi-Device Authority Context
An AI-agent task may use several devices.
For example:
| x | A GPU performs computation. |
| - | ----------------------------------------- |
| x | A storage controller provides model data. |
| x | A DPU performs network transport. |
| x | A SmartNIC transmits outputs. |
| x | A DMA controller transfers buffers. |
Each device may maintain different queues, mappings, and authority
state.
A common task authority may therefore require coordination across
multiple device-specific enforcement mechanisms.
7.3.87. S-8.52 - Cross-Device Authority Generation
A Cross-Device Authority Generation means an authority version
associated with a defined set of cooperating devices or effectuation
interfaces.
A representative record comprises:
AuthorityGeneration = 621
AgentContextID = AGENT-42
AffectedDevices = GPU-02, DPU-02, NIC-03
RestrictedOperationClasses = CLASS-A
RequiredFencingState = FENCE-621
ConvergenceStatus = PENDING
The generation may be maintained by a protected coordinator.
Each device may maintain a corresponding applied-generation state.
7.3.88. S-8.53 - Distributed Hardware Fencing
A cross-device fencing procedure may:
Das Expires 25 April 2027 [Page 210]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Identify affected devices. 2. Advance the protected authority
generation. 3. Restrict new operation admission. 4. Identify
outstanding commands. 5. Apply device-specific cancellation or
fencing. 6. Obtain state acknowledgments. 7. Determine whether
outstanding effects remain possible. 8. Apply compensating
restrictions. 9. Record convergence or unresolved state.
An acknowledgment that a device has updated its policy does not
necessarily prove that all previously admitted operations have
stopped.
The claimed semantics determine whether admission convergence,
execution convergence, or full effectuation quiescence is required.
7.3.89. S-8.54 - Cross-Device Completion Watermark
The system may associate a completion watermark with each relevant
device or queue.
For example:
GPU-02: LastRetired = 1200
DPU-02: LastRetired = 850
NIC-03: LastTransmitted = 900
The values are illustrative and refer to separately defined device-
local sequences.
A protected coordinator may determine whether the required operations
have completed or been canceled according to the relevant watermarks
and device-specific status.
No general numeric comparison between unrelated device-local sequence
values is implied.
7.3.90. PART XIV - PRINCIPAL EXECUTION WORKFLOW
7.3.91. S-8.55 - Complete 32-Step Hardware Finality Workflow
7.3.92. Step S8-01 - Hardware resource initialization
The computing platform initializes the selected processors,
accelerators, network devices, and related controllers.
Das Expires 25 April 2027 [Page 211]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.93. Step S8-02 - Device security configuration
The system establishes the applicable hardware memory and resource
isolation settings.
7.3.94. Step S8-03 - Device identity establishment
Required devices are associated with authenticated or protected
device identities.
7.3.95. Step S8-04 - Authority-generation initialization
The protected authority controller establishes the current
generation.
7.3.96. Step S8-05 - Execution-context registration
The agent, task, device, and permitted resource scope are associated
with a machineverifiable context.
7.3.97. Step S8-06 - Memory ownership configuration
Required memory regions are assigned to the intended execution
context.
7.3.98. Step S8-07 - DMA access configuration
The system establishes permitted DMA mappings and memory-access
restrictions.
7.3.99. Step S8-08 - Command-interface control
The system configures applicable command submission and effectuation
interfaces.
7.3.100. Step S8-09 - Effectuation-path verification
The system identifies the relevant alternative device paths capable
of producing governed effects.
7.3.101. Step S8-10 - Agent computation
The agent performs ordinary computation.
7.3.102. Step S8-11 - Hardware operation proposal
The agent generates a consequential device or accelerator operation.
Das Expires 25 April 2027 [Page 212]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.103. Step S8-12 - Operation interception
The command is captured before its governed effectuation boundary.
7.3.104. Step S8-13 - Candidate Hardware Act construction
The system creates a machine-readable command representation.
7.3.105. Step S8-14 - Non-effective command staging
The operation remains withheld.
7.3.106. Step S8-15 - Actual device-context association
The command is associated with its authenticated device and execution
context.
7.3.107. Step S8-16 - Descriptor canonicalization
The required command parameters and resource identifiers are
represented deterministically.
7.3.108. Step S8-17 - PED submission
The descriptor is submitted to protected authorization.
7.3.109. Step S8-18 - Protected authority-state retrieval
The PED obtains current authority, ownership, and revocation state.
7.3.110. Step S8-19 - Required predicate evaluation
The PED validates the operation-specific conditions.
7.3.111. Step S8-20 - Protected validation evidence commitment
The required evidence is committed.
7.3.112. Step S8-21 - Scoped finality capability establishment
Bounded finality authorization is activated.
7.3.113. Step S8-22 - Command presentation
The staged command reaches the authorized device Finality Sink.
Das Expires 25 April 2027 [Page 213]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.114. Step S8-23 - Actual pending command reconstruction
The sink obtains the command representation that will actually be
admitted or executed.
7.3.115. Step S8-24 - Capability verification
The sink verifies the required evidence, capability, and operation
bindings.
7.3.116. Step S8-25 - Authority-generation verification
The sink checks the current applicable authority and ownership
generations.
7.3.117. Step S8-26 - Memory-access verification
The sink checks required memory-scope or device-access conditions.
7.3.118. Step S8-27 - Protected consumption transition
The sink reserves or consumes the authorization according to the
usage policy.
7.3.119. Step S8-28 - Hardware command admission
The command is admitted through the controlled interface.
7.3.120. Step S8-29 - Hardware execution
The device executes the authorized command.
7.3.121. Step S8-30 - Completion observation
The relevant device completion state is obtained.
7.3.122. Step S8-31 - Effectuation outcome reconciliation
The protected operation state is updated or marked unresolved.
7.3.123. Step S8-32 - Resource lifecycle update
The relevant device, queue, and ownership state are updated according
to the selected resource-management policy.
Das Expires 25 April 2027 [Page 214]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.124. PART XV - REFERENCE ALGORITHMS
S-8.56 - Algorithm A: Hardware Security Initialization function
InitializeHardwareSandbox(configuration):
devices = EnumerateRequiredDevices(configuration)
for each device in devices:
if not VerifyRequiredDeviceCapabilities(
device, configuration.required_properties[device]
):
return DENIED
InitializeDeviceIsolation(device)
InitializeProtectedDeviceContext(device)
if not VerifyRequiredEffectuationControl(device):
return DENIED authority_generation =
AllocateProtectedAuthorityGeneration()
RegisterProtectedHardwareConfiguration({
devices: devices, authority_generation: authority_generation,
security_profile: configuration.profile })
if not VerifyGovernedEffectuationPathCoverage():
RestrictGovernedOperations() return DENIED return ACTIVE
The verification functions must correspond to actual platform
capabilities.
A generic return value indicating success does not establish that
unsupported hardware protections exist.
7.3.125. S-8.57 - Algorithm B: Hardware Command Capture
function CaptureHardwareCandidate(source, command):
context = AuthenticateDeviceExecutionContext(source)
if context is invalid:
Das Expires 25 April 2027 [Page 215]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED
if not VerifyCurrentContextGeneration(context):
return DENIED controlled_command =
CaptureStableCommandRepresentation(
command )
if not IsGovernedHardwareEffect(controlled_command):
return EvaluateApplicableOrdinaryHardwarePolicy(
controlled_command )
candidate_id = AllocateCandidateActID()
descriptor = Canonicalize({
candidate_id: candidate_id, execution_context: context, device_id:
controlled_command.device_id, command_class:
controlled_command.class, command_parameters:
controlled_command.parameters, memory_scope:
controlled_command.memory_scope, authority_generation:
CurrentAuthorityGeneration(context), ownership_generation:
CurrentOwnershipGeneration(context), intended_sink:
ResolveHardwareFinalitySink(controlled_command) })
ProtectedCommandRegistry.stage(
candidate_id, controlled_command, descriptor )
return PED.Validate(candidate_id, descriptor)
The command must remain non-effective with respect to the designated
consequence during protected validation.
S-8.58 - Algorithm C: Protected Hardware Authorization
function ValidateHardwareCandidate(candidate_id, descriptor):
record = ProtectedCommandRegistry.get(candidate_id)
if record.status != STAGED:
return DENIED
if not VerifyDeviceAndContextBinding(descriptor, record):
Das Expires 25 April 2027 [Page 216]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED authority =
ProtectedAuthorityRegistry.lookup(descriptor)
if not VerifyCurrentAuthorityGeneration(authority):
return DENIED
if not VerifyResourceOwnership(
descriptor, authority ):
return DENIED if not EvaluateRequiredHardwarePredicates(
descriptor, authority ):
ProtectedCommandRegistry.deny(candidate_id) return DENIED evidence =
CommitProtectedValidationEvidence(
candidate_id, descriptor, authority )
capability = CreateScopedHardwareFinalityCapability({
candidate_id: candidate_id, evidence_reference: evidence.id,
descriptor_digest: HashCanonical(descriptor), device_id:
descriptor.device_id, intended_sink: descriptor.intended_sink,
authority_generation: authority.generation, ownership_generation:
descriptor.ownership_generation })
if not ActivateAuthorizationAtomically(
candidate_id, evidence, capability ):
DisableCapability(capability) return DENIED
return AUTHORIZED
The implementation must ensure the required protected ordering among
evidence commitment, capability activation, and command
authorization.
7.3.126. S-8.59 - Algorithm D: Hardware Finality Sink
function ExecuteAuthorizedHardwareCommand(candidate_id):
record = ProtectedCommandRegistry.get(candidate_id)
if record.status != AUTHORIZED:
Das Expires 25 April 2027 [Page 217]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED
actual_command = ReadControlledPendingCommand(candidate_id)
if actual_command is unavailable:
return DENIED evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
if not VerifyProtectedEvidence(evidence):
return DENIED
if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED
if not VerifyActualHardwareCommand(
actual_command, capability ):
return DENIED if not VerifyCurrentDeviceAuthorityGeneration(
capability ):
return DENIED if not VerifyCurrentOwnershipGeneration(
actual_command, capability ):
return DENIED
if not VerifyRequiredMemoryAccessScope(
actual_command ):
return DENIED
if not VerifySinkLocalProtectedState(capability):
return DENIED if not ReserveCapabilityAtomically(capability):
Das Expires 25 April 2027 [Page 218]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED result = AdmitCommandThroughControlledDeviceInterface(
actual_command )
RecordOrReconcileHardwareOutcome(
candidate_id, result )
return result
If the enforcement point governs actual execution rather than
admission, the enforcement architecture must also prevent prohibited
execution after admission.
S-8.60 - Algorithm E: Cross-Device Authority Fencing
function FenceCrossDeviceAuthority(context, restriction):
generation = AdvanceProtectedAuthorityGeneration(
context )
devices = ResolveAffectedDevices(context, restriction)
for each device in devices:
BlockNewProhibitedCommandAdmissions(
device, generation, restriction )
for each device in devices:
outstanding = EnumerateRelevantOutstandingCommands(
device, restriction
)
ApplySupportedCommandFencing(
device, outstanding, generation )
states = CollectDeviceFencingStates(
devices, generation )
if not VerifyRequiredSafetyCondition(states):
Das Expires 25 April 2027 [Page 219]
Internet-Draft Kernel-Hardware Execution Finality October 2026
ApplyCompensatingRestrictions(devices) return FENCING_INCOMPLETE
CommitProtectedFencingCompletion(
context, generation, states )
return FENCED
The required safety condition may concern only admission of new
commands or may additionally require resolution of all previously
admitted effect-capable commands.
The implementation must not conflate these distinct guarantees.
7.3.127. S-8.61 - Algorithm F: DMA Access Revocation
function RevokeDMAAccess(device_context, memory_range):
BlockNewDMACommandAdmission(
device_context, memory_range )
outstanding = EnumerateRelevantDMAOperations(
device_context, memory_range )
ApplySupportedDMAFencing(
device_context, outstanding )
UpdateDeviceMemoryMappings(
device_context, memory_range, DENY_ACCESS )
IssueRequiredTranslationInvalidations(
device_context, memory_range )
if not VerifyTranslationInvalidationCompletion(
device_context ):
return RESTRICTED
if not VerifyRequiredOutstandingDMAResolution(
device_context, memory_range ):
Das Expires 25 April 2027 [Page 220]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return RESTRICTED
CommitProtectedDMARevocationState(
device_context, memory_range )
return REVOKED
The procedure must use the relevant platform-specific IOMMU, device,
and interconnect mechanisms.
A translation invalidation does not independently establish complete
cancellation of unrelated outstanding operations.
S-8.62 - Algorithm G: Verified Device Memory Reassignment
function ReassignDeviceMemory(
allocation_id, current_owner, new_owner ):
allocation = ProtectedMemoryRegistry.get(allocation_id)
if allocation.owner != current_owner:
return DENIED
MarkAllocationReassignmentPending(allocation)
if not BlockNewPriorOwnerOperations(allocation):
return DENIED
if not FenceRelevantDeviceQueues(allocation):
return RESTRICTED if not
ResolveOutstandingMemoryAccesses(allocation):
return RESTRICTED if not RevokePriorOwnerMappings(allocation):
return RESTRICTED
if not CompleteRequiredTranslationInvalidations(allocation):
return RESTRICTED if not VerifyResourceQuiescence(allocation):
return RESTRICTED
result = PerformSelectedSanitization(allocation)
Das Expires 25 April 2027 [Page 221]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if result != SUCCESS:
return RESTRICTED
if not VerifySanitizationCoverage(allocation):
return RESTRICTED
new_generation = AdvanceOwnershipGeneration(allocation)
UpdateProtectedMemoryOwnership(
allocation, new_owner, new_generation )
EstablishNewOwnerMappings(allocation, new_owner)
return REASSIGNED
The sequence prevents the resource from becoming available to the new
owner before the required prior-owner access restrictions and
sanitization conditions are satisfied.
7.3.128. S-8.63 - Algorithm H: Hardware Recovery
function RecoverHardwareEnforcement():
protected_state = RecoverProtectedAuthorityState()
if not VerifyProtectedStateContinuity(protected_state):
RestrictAffectedDevices() return RECOVERY_REQUIRED
devices = EnumerateGovernedDevices()
for each device in devices:
state = RecoverOrInspectDeviceState(device)
if state is unreliable:
RestrictDeviceEffects(device) continue
ReconcileOutstandingCommandState(
device, state )
VerifyAppliedAuthorityGeneration(
Das Expires 25 April 2027 [Page 222]
Internet-Draft Kernel-Hardware Execution Finality October 2026
device, protected_state )
VerifyRelevantMemoryOwnership(
device, protected_state )
if not VerifyRequiredDeviceEnforcementCoverage():
return RESTRICTED
return ACTIVE
Recovery must distinguish commands that are confirmed completed,
confirmed not executed, canceled, and potentially effected but
unresolved.
7.3.129. PART XVI - WORKED TECHNICAL EXAMPLES
S-8.64 - Example A: GPU Model Output With Protected Egress
The following is a hypothetical implementation example.
An AI agent executes a model on a GPU.
The GPU produces an output tensor containing information associated
with an enterprise task.
The output remains in a controlled accelerator buffer.
The agent requests transmission of a derived report to an external
service.
The controlled interface constructs a Candidate Act identifying:
| x | The originating agent. |
| - | -------------------------------------- |
| x | The task. |
| x | The intended recipient. |
| x | The relevant output or payload digest. |
| x | The applicable data scope. |
| x | The authority generation. |
| x | The intended egress Finality Sink. |
The PED evaluates whether the output may be released to the selected
recipient.
Protected validation evidence is committed.
Das Expires 25 April 2027 [Page 223]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A scoped non-bearer capability is established.
A protected network Finality Sink obtains the actual pending
transmission.
The sink verifies the required authorization.
Only the authorized output is transmitted.
The GPU's successful computation does not, by itself, authorize the
external transmission.
S-8.65 - Example B: DPU-Controlled Agent Network Operation
An AI agent operates within a cloud-hosted virtual machine.
A DPU provides protected control over selected network-egress
interfaces.
The agent generates a network operation.
The request reaches a controlled host-to-DPU operation path.
The operation is staged and associated with the authenticated
workload context.
The PED evaluates the permitted destination, operation scope, and
policy generation.
Protected evidence and bounded finality authorization are
established.
The DPU-controlled Finality Sink verifies the actual pending network
effect.
The device permits transmission only if the required authorization
succeeds.
An alternative host networking path must be restricted or mediated if
the deployment enforcement points non-bypassability for that network
effect.
7.3.130. S-8.66 - Example C: DMA Isolation of Agent Memory
An accelerator is assigned to an agent workload.
The resource manager configures an IOMMU domain permitting the device
to access selected memory regions.
Das Expires 25 April 2027 [Page 224]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The agent attempts to cause the device to write outside the permitted
memory scope.
The device's effective memory request is checked against the
supported IOMMU access restrictions.
The unauthorized access is rejected according to the hardware
mechanism.
In an optional protected-finality variation, a PED additionally
authorizes the specific device operation before command admission.
This example illustrates that hardware memory isolation and
operation-specific finality may cooperate while remaining technically
distinct.
S-8.67 - Example D: Revocation During GPU Queue Execution
An agent has submitted multiple GPU operations.
Some commands have completed.
Others remain queued or executing.
A protected authority controller revokes the relevant task authority.
The system advances the hardware authority generation.
New commands associated with the revoked authority are withheld.
The hardware fencing controller identifies outstanding commands.
Commands not yet executing may be canceled where supported.
Executing commands may require a supported preemption, queue-drain,
or device-reset procedure, depending upon the relevant effect and
device capabilities.
The system does not declare complete execution fencing until the
required state of outstanding operations has been established.
S-8.68 - Example E: Accelerator Memory Sanitization Before Tenant
Reassignment
Tenant A uses an AI accelerator.
The accelerator contains allocated memory associated with Tenant A's
model operations.
Das Expires 25 April 2027 [Page 225]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Tenant A's workload terminates.
The resource manager prepares to assign the memory to Tenant B.
The protected ownership controller marks the allocation
REASSIGNMENT_PENDING.
The system prevents new Tenant A operations.
The relevant command queues are fenced.
Outstanding memory accesses are resolved.
Prior mappings are revoked.
Required translation invalidations are completed.
The memory-sanitization mechanism clears the memory within its stated
coverage.
The system verifies completion of the required sanitization
procedure.
Only then is a new ownership generation established and access
granted to Tenant B.
The architecture does not treat termination of Tenant A's process as
proof that its device memory has already been sanitized.
S-8.69 - Example F: Peer-to-Peer GPU-to-NIC Transfer
A GPU contains a computed output.
A network device supports an applicable peer-to-peer data-transfer
path.
The agent requests transfer of the GPU output to an external
destination.
A protected authorization system evaluates the output-release scope.
The corresponding Finality Sink controls the peer-to-peer transfer or
the final network transmission.
The implementation constrains the relevant DMA and device command
interfaces so that the output cannot reach the network through an
uncontrolled path.
Das Expires 25 April 2027 [Page 226]
Internet-Draft Kernel-Hardware Execution Finality October 2026
If the GPU can otherwise expose the same data through an unrestricted
alternate transfer path, the claimed non-bypassability property is
not established for that data release.
7.3.131. S-8.70 - Example G: Cross-Device Revocation
An agent task uses a GPU, storage controller, and DPU.
The task's authority is reduced.
A protected coordinator advances the authority generation.
The GPU controller rejects new commands associated with the earlier
generation.
The storage controller applies the required write restriction.
The DPU restricts corresponding network transfers.
Each device reports its applied generation and relevant outstanding-
operation status.
The coordinator determines whether the required restriction has
converged.
If one device remains capable of performing a prohibited operation,
the system applies the appropriate compensating restriction or
records incomplete convergence.
A central policy update alone is not treated as proof of full
hardware effectuation control.
S-8.71 - Example H: Hardware Reset With Indeterminate Operations
A device executes a command that may have modified an external
resource.
The device resets before the host receives a reliable completion
record.
Following restart, the recovery controller obtains the available
protected operation and device-state records.
The operation is classified as potentially effected but unresolved.
The system does not automatically issue the same command again.
Das Expires 25 April 2027 [Page 227]
Internet-Draft Kernel-Hardware Execution Finality October 2026
It performs the available resource-state or external-operation
reconciliation procedure.
Where no reliable completion determination is possible, the
unresolved status is preserved according to the applicable policy.
7.3.132. PART XVII - FAILURE AND ADVERSARIAL SCENARIOS
7.3.133. S-8.72 - Representative Failure Conditions
7.3.134. F1 - Uncontrolled GPU Command Queue
The agent submits a command through an unmediated queue.
A protected-finality deployment must control or exclude this path for
the claimed effect.
7.3.135. F2 - Device Command Substitution
The actual device command differs from the previously authorized
descriptor.
The Finality Sink detects the material mismatch.
7.3.136. F3 - Stale Authority Generation
A command refers to an unacceptable authority generation.
The applicable protected controller rejects the command.
7.3.137. F4 - Stale Ownership Generation
A command attempts to use memory assigned to a subsequent owner.
The ownership-generation check prevents unauthorized access.
7.3.138. F5 - IOMMU Mapping Error
A device receives a broader memory mapping than permitted.
The configuration or verification mechanism identifies the violation.
7.3.139. F6 - DMA Translation Staleness
A device retains an old translation after mapping revocation.
The required invalidation and completion procedures address the stale
state.
Das Expires 25 April 2027 [Page 228]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.140. F7 - In-Flight DMA After Revocation
A DMA write remains capable of completing after software revokes the
mapping.
The implementation applies the necessary device-specific fencing and
outstanding-operation checks.
7.3.141. F8 - GPU Memory Reuse Without Sanitization
A memory allocation is assigned to a new tenant while residual data
remains accessible.
The reassignment procedure withholds access pending the required
sanitization.
7.3.142. F9 - Sanitization Before Queue Drain
Memory is cleared while a prior command remains capable of writing to
it.
The resource is not released until the required outstanding-operation
safety condition is satisfied.
7.3.143. F10 - Incomplete Sanitization Coverage
A memory-clearing operation does not cover the resource extent
included in the security guarantee.
The verification mechanism rejects or restricts reassignment.
7.3.144. F11 - Unverified Cryptographic Erasure
A key is deleted, but residual plaintext or key copies remain outside
the protected encryption domain.
The system cannot represent the complete memory resource as securely
erased based solely on key deletion.
7.3.145. F12 - Peer-to-Peer Bypass
A device transfers data through an uncontrolled peer-to-peer path.
The deployment restricts or mediates that path where necessary for
the enforcement point.
Das Expires 25 April 2027 [Page 229]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.146. F13 - Unauthorized Device Pass-Through
A virtual machine obtains direct access to an effect-capable device.
The relevant device interface must be controlled or excluded from the
governed execution configuration.
7.3.147. F14 - Firmware Authorization Bypass
A device exposes a command path that ignores the protected
authorization mechanism.
The claimed finality property is not established until the bypass is
addressed.
7.3.148. F15 - Capability Replay
A consumed single-use hardware authorization is presented again.
Protected sink-local state rejects the replay.
7.3.149. F16 - Concurrent Capability Use
Two command workers attempt to consume the same single-use
authorization.
An atomic protected state transition restricts use according to the
capability policy.
7.3.150. F17 - Device Reset Clears Revocation State
A device reset removes volatile policy restrictions.
The recovery process restricts governed operations until the required
current authorization state has been restored.
7.3.151. F18 - Queue Completion Misinterpretation
A queue acknowledgment is treated as proof of physical or external
completion despite lacking that meaning.
The operation-state model distinguishes the actual completion
semantics.
7.3.152. F19 - Cross-Device Generation Mismatch
One device applies a new restriction while another uses stale
authority.
Das Expires 25 April 2027 [Page 230]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The convergence controller detects or prevents unauthorized
inconsistent execution according to the enforcement point.
7.3.153. F20 - Command Cancellation Unsupported
A device does not support cancellation of a selected running
operation.
The implementation identifies the limitation and employs a supported
alternative or maintains an unresolved restriction state.
7.3.154. F21 - Hardware Quiescence Misclassification
A device reports low activity but still has outstanding memory
accesses.
The quiescence procedure checks the relevant device and operation
state rather than relying solely on utilization.
7.3.155. F22 - Protected Register Tampering
An unauthorized component attempts to modify a protected device
register.
The selected hardware protection prevents the modification according
to its threat model.
7.3.156. F23 - Device Identity Substitution
Authorization intended for one device is presented to another.
The required device-identity binding is verified.
7.3.157. F24 - Queue Identity Substitution
A capability authorized for one queue is applied to a different
queue.
The sink checks the applicable queue binding where required.
7.3.158. F25 - Hardware Command Parameter Expansion
A command is modified to access a broader memory or resource scope.
Actual command verification detects the unauthorized expansion.
Das Expires 25 April 2027 [Page 231]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.159. F26 - GPU Context Reuse
A recycled accelerator execution-context identifier is mistaken for
an earlier authorized context.
The protected context-generation mechanism distinguishes the
instances.
7.3.160. F27 - Cross-Tenant Resource Alias
Different logical identifiers reference the same underlying protected
hardware resource.
The ownership controller resolves or verifies the actual resource
association.
7.3.161. F28 - Device Firmware Downgrade
A firmware version lacking required enforcement is installed.
The system rejects the unsupported security state when the
corresponding firmware guarantee is mandatory.
7.3.162. F29 - Host-Kernel Compromise
The host kernel is compromised.
A host-software-only device authorization mechanism may fail.
Hardware-backed protection is required if the enforcement point
includes resistance to that adversary.
7.3.163. F30 - Device Controller Compromise
The device's protected firmware or controller is compromised.
The security guarantee depends upon the actual hardware trust and
recovery model.
7.3.164. F31 - Hardware Queue Resource Exhaustion
The command queue becomes full or the enforcement controller cannot
allocate required state.
The system applies the defined restriction or failure response rather
than interpreting resource exhaustion as authorization.
Das Expires 25 April 2027 [Page 232]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.165. F32 - Memory Ownership Registry Rollback
An earlier resource ownership generation is restored.
Protected state continuity detects or prevents prohibited reuse.
7.3.166. F33 - Device Hot-Plug or Removal
A device is removed or replaced during operation.
The system invalidates or re-establishes the required device identity
and authority association.
7.3.167. F34 - Accelerator Migration
A workload moves to a different accelerator.
The destination device receives only the authority and memory
resources permitted under the applicable migration procedure.
7.3.168. F35 - External Operation Acknowledgment Lost
A device-generated operation may have produced an effect, but the
completion acknowledgment is lost.
The system retains an indeterminate operation state.
7.3.169. F36 - Protected State Recovery Failure
Required authority, ownership, or consumption state cannot be
recovered reliably.
The affected governed operation paths remain restricted.
7.3.170. PART XVIII - IMPLEMENTATION VARIATIONS
7.3.171. S-8.73 - GPU-Only Resource Isolation
A GPU execution environment may provide selected memory, context, and
command restrictions without requiring the full protected-finality
sequence.
This variation may support independent enforcement points directed to
isolation, resource ownership, or sanitization.
It does not automatically satisfy enforcement points requiring
protected validation evidence and scoped non-bearer finality
capabilities.
Das Expires 25 April 2027 [Page 233]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.172. S-8.74 - GPU With Software PED
A protected host service evaluates selected GPU operations.
| The driver or controlled accelerator interface implements the required Finality Sink. The security model relies on the integrity of the relevant host and driver enforcement components. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-8.75 - GPU With Hardware CIED A hardware-protected or cryptographically isolated component performs protected authorization. A controlled accelerator command processor or equivalent device interface verifies the required authorization before the governed effect. The implementation must establish actual coupling between the protected authorization and device effectuation. |
| S-8.76 - SmartNIC-Only Egress Control A SmartNIC may control selected network transmissions independently of GPU operation authorization. The SmartNIC serves as the Finality Sink only for the effects it can actually prevent or permit. |
7.3.173. S-8.77 - DPU and GPU Cooperative Enforcement
A GPU performs computation.
A DPU controls selected data transfers or network effects.
A PED evaluates required authorization conditions.
The DPU or another protected controller verifies actual output-
release operations.
The arrangement may additionally use protected device memory
mappings.
7.3.174. S-8.78 - FPGA-Based Enforcement
A programmable logic region may implement operation-descriptor
verification, protected registers, authorization latches, bounded
counters, or effectuation gating.
The FPGA's configuration and authority-critical state must be
protected according to the applicable enforcement point.
7.3.175. S-8.79 - ASIC-Based Finality Controller
A dedicated hardware controller may implement:
1. Candidate command capture. 2. Protected authorization lookup. 3.
Descriptor comparison. 4. Capability-state verification. 5. Atomic
usage-state transition. 6. Controlled operation release.
The functions may be implemented through logic circuits, register
files, protected memories, or hardware state machines.
7.3.176. S-8.80 - IOMMU-Based Memory Isolation
An IOMMU may restrict memory accesses by permitted devices.
Das Expires 25 April 2027 [Page 234]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The implementation may operate independently of the broader
protected-finality mechanism where a enforcement point concerns only
memory-access isolation.
Where operation-specific authority is required, corresponding
authorization is added through a suitable protected controller.
7.3.177. S-8.81 - Cross-Device Protected Controller
A protected controller may coordinate authority generations across
several devices.
The controller may maintain a registry of device identities, resource
ownership, outstanding commands, and applied enforcement generations.
Each device implements the restrictions that its actual hardware
capabilities support.
7.3.178. S-8.82 - Device Memory Sanitization Without Finality
Capability
A device resource manager may implement a protected sanitization and
reassignment sequence independently of a Candidate Act receipt-
capability architecture.
The sequence may include queue fencing, mapping invalidation,
sanitization, completion verification, and ownership-generation
transition.
This variation supports an independently claimed hardware memory-
protection invention where its limitations are expressly disclosed.
| S-8.83 - TEE/HSM-Assisted Hardware Authorization A TEE or HSM provides protected authorization, key custody, evidence commitment, or capability activation. A hardware device acts as the Finality Sink. The implementation must provide the required protected communication and operation binding. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-8.84 - Single-Chip Integrated Implementation A system-on-chip may contain general-purpose processors, accelerator units, protected memory, device controllers, and finality-enforcement logic. The relevant security roles may be implemented within one chip. Physical separation is not required unless the applicable claim expressly imposes it. |
| S-8.85 - Distributed Hardware Implementation Multiple devices located on different computing nodes may cooperate through authenticated communication and protected generation state. The system may govern cross-device operations and enforce bounded authorization at each relevant effectuation boundary. Network partitions and incomplete state convergence must be handled according to the selected claim. |
7.3.179. PART XIX - TECHNICAL DATA STRUCTURES
7.3.180. S-8.86 - HardwareExecutionContextRecord
Fields may include:
1. ExecutionContextID. 2. AgentContextID. 3. TaskID. 4. DeviceID.
5. DeviceContextID. 6. ExecutionGeneration. 7.
AuthorityGeneration. 8. SecurityProfile. 9.
PermittedCommandClasses. 10. LifecycleStatus.
Das Expires 25 April 2027 [Page 235]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.181. S-8.87 - DeviceAuthorityRecord
Fields may include:
1. DeviceAuthorityDomainID. 2. DeviceID. 3. AgentOrTenantID. 4.
TaskID. 5. AuthorityGeneration. 6. RevocationGeneration. 7.
PermittedResources. 8. PermittedCommandClasses. 9.
ProtectedPolicyReference. 10. CurrentEnforcementState.
7.3.182. S-8.88 - HardwareCandidateActRecord
Fields may include:
1. CandidateActID. 2. HardwareCommandID. 3.
OriginatingExecutionContext. 4. DeviceID. 5. QueueID. 6.
CommandClass. 7. CommandDescriptorDigest. 8. AuthorityGeneration.
9. OwnershipGeneration. 10. CandidateStatus.
7.3.183. S-8.89 - HardwareValidationEvidenceRecord
Fields may include:
1. EvidenceID. 2. CandidateActID. 3. CommandDescriptorDigest. 4.
PEDIdentity. 5. AuthorityGeneration. 6. OwnershipGeneration. 7.
ValidationResult. 8. ProtectedEvidenceCommitment. 9.
EvidenceGeneration. 10. RequiredSinkID.
7.3.184. S-8.90 - HardwareFinalityCapabilityRecord
Fields may include:
1. CapabilityID. 2. CandidateActID. 3. EvidenceReference. 4.
CommandDescriptorDigest. 5. AuthorizedDevice. 6. AuthorizedQueue.
7. PermittedCommandScope. 8. AuthorityGeneration. 9.
OwnershipGeneration. 10. UsagePolicy. 11. CapabilityStatus. 12.
ProtectedConsumptionReference.
7.3.185. S-8.91 - DeviceQueueStateRecord
Fields may include:
1. DeviceID. 2. QueueID. 3. QueueGeneration. 4.
LastSubmittedSequence. 5. LastAdmittedSequence. 6.
LastScheduledSequence. 7. LastCompletedSequence. 8.
LastRetiredSequence. 9. FencingState. 10.
OutstandingCommandReferences.
Das Expires 25 April 2027 [Page 236]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.186. S-8.92 - DMAAccessRecord
Fields may include:
1. DMAOperationID. 2. RequestingDeviceID. 3. ExecutionContextID.
4. IOMMUDomainID. 5. MemoryRangeReference. 6. AccessDirection. 7.
MappingGeneration. 8. TranslationInvalidationState. 9.
OutstandingTransferState. 10. CompletionState.
7.3.187. S-8.93 - DeviceMemoryOwnershipRecord
Fields may include:
1. AllocationID. 2. DeviceID. 3. OwnerTenantID. 4.
OwnerExecutionContext. 5. OwnershipGeneration. 6. MemoryRange. 7.
ActiveMappingReferences. 8. ActiveCommandReferences. 9.
SanitizationStatus. 10. ReassignmentStatus.
7.3.188. S-8.94 - SanitizationEvidenceRecord
Fields may include:
1. SanitizationID. 2. AllocationID. 3. PreviousOwner. 4.
PreviousOwnershipGeneration. 5. SanitizationMethod. 6.
CoveredMemoryRange. 7. RequiredQuiescenceReference. 8.
MappingInvalidationReference. 9. SanitizationCompletionStatus. 10.
VerificationResult.
11. NewOwnershipGeneration.
7.3.189. S-8.95 - CrossDeviceFencingRecord
Fields may include:
1. FencingGeneration. 2. AgentOrTaskContext. 3. AffectedDeviceIDs.
4. RestrictedOperationClasses. 5. DeviceAppliedGenerations. 6.
OutstandingCommandReferences. 7. CompletionWatermarks. 8.
RequiredSafetyCondition. 9. ConvergenceStatus. 10.
CompensatingRestrictions.
7.3.190. S-8.96 - HardwareRecoveryRecord
Fields may include:
1. RecoveryGeneration. 2. DeviceID. 3.
LastProtectedAuthorityGeneration. 4.
LastAcceptedOwnershipGeneration. 5. OutstandingCommands. 6.
UnresolvedDMAOperations. 7.
Das Expires 25 April 2027 [Page 237]
Internet-Draft Kernel-Hardware Execution Finality October 2026
ProtectedCapabilityConsumptionReferences. 8.
SanitizationPendingResources. 9. RequiredFencingActions. 10.
RecoveryStatus.
These records may be implemented using device firmware structures,
protected registers, secure memories, authenticated host registries,
transactionally protected software state, or combinations thereof.
7.3.191. PART XX - implementer VERIFICATION TESTS
7.3.192. S-8.97 - Representative Engineering Test Matrix
The following are proposed verification procedures, not
representations of experiments already performed.
Test Technical condition Expected behavior
T1 Valid hardware command
authorization
T2 Missing capability T3 Invalid evidence T4 Replayed single-use
capability T5 Modified hardware command T6 Wrong device identity T7
Wrong queue identity T8 Stale authority generation T9 Stale ownership
generation T10 Unauthorized DMA mapping T11 DMA mapping revocation
T12 In-flight DMA after revocation T13 Device pass-through bypass T14
Peer-to-peer transfer bypass T15 GPU output release without
authorization T16 Command replay after device reset T17 Concurrent
capability use T18 Hardware queue fencing T19 Outstanding queued
operation T20 Incomplete quiescence T21 Memory not fully sanitized
T22 Sanitization after prior-owner writes T23 Cryptographic erasure
with residual
plaintext T24 Tenant reassignment T25 GPU context identifier reuse
T26 Multi-device generation mismatch T27 Device reset loses volatile
restrictions Recovery reestablishes required controls T28 Firmware
downgrade T29 Alternate command interface T30 Protected register
tampering T31 Hardware recovery after incomplete
dispatch T32 Unreliable completion watermark T33 Cross-device fencing
incomplete T34 Memory ownership registry rollback Stale state
detected T35 Device replacement T36 Device resource exhaustion
Governed operation permitted Effect withheld Effect withheld Rejected
Mismatch detected Authorization rejected Required binding enforced
Command restricted Access rejected Access denied Required
invalidation completed Required safety condition enforced Governed
Das Expires 25 April 2027 [Page 238]
Internet-Draft Kernel-Hardware Execution Finality October 2026
effect restricted Controlled or denied Release withheld Protected
state prevents unauthorized reuse Atomic consumption enforced
Required new-command restrictions applied Required cancellation or
continuation semantics applied Reassignment withheld Reassignment
withheld Required ordering enforced Incomplete protection recognized
New ownership generation verified Stale authorization rejected
Convergence failure recognized
Required version policy enforced Controlled or excluded Unauthorized
modification prevented under defined model Unresolved operations
reconciled No unsupported completion enforcement point Restriction
remains unresolved
Authority and ownership revalidated Defined restrictive behavior
T37 GPU-to-NIC unauthorized transfer T38 Shared accelerator tenant
separation T39 Stale device-side translation T40 Failed sanitization
controller
Protected release restriction enforced Actual supported isolation
guarantees tested Required mapping safety enforced Resource not
released as sanitized
Each test should be adapted to the actual device architecture.
Platform-specific validation must account for the differences among
command admission, execution completion, memory translation, device
synchronization, and external effectuation.
7.3.193. PART XXI - Enforcement-Point Mapping and Technical
Correspondence
7.3.194. S-8.98 - Enforcement-Point Mapping and Technical
Correspondence
this implementation profile provides representative technical
disclosure relevant to proposed enforcement points concerning:
(a) hardware and firmware AI-agent sandboxing;
(b) SmartNIC/DPU enforcement;
(c) GPU and accelerator execution isolation;
(d) IOMMU memory-access controls;
(e) DMA operation restriction;
Das Expires 25 April 2027 [Page 239]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(f) hardware Candidate Act staging;
(g) protected validation evidence;
(h) scoped non-bearer hardware finality capabilities;
(i) hardware Finality Sink verification;
(j) actual pending device-command reconstruction;
(k) hardware authority generations;
(l) queue admission and execution control;
(m) cross-device fencing;
(n) protected device command consumption;
(o) completion watermarks;
(p) device memory ownership;
(q) accelerator memory sanitization;
(r) verified tenant reassignment;
(s) peer-to-peer transfer restrictions;
(t) asynchronous device operation recovery; and
(u) hardware-software hybrid enforcement.
The embodiment is particularly relevant to the proposed hardware-
related independent enforcement point(s) 76, 84, 93, and 97 and their
applicable dependent-enforcement point families.
It may also contribute implementation support to enforcement point(s)
1, 9, 21, 33, and other enforcement points requiring hardware
variants of protected effectuation control.
The correspondence is provisional. Each finalized enforcement point
must be checked against the actual disclosed components, algorithms,
state transitions, and implementation alternatives.
7.3.195. PART XXII - implementer IMPLEMENTATION REQUIREMENTS
Das Expires 25 April 2027 [Page 240]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.196. S-8.99 - Hardware Implementation Checklist
For a selected accelerator, SmartNIC, DPU, storage controller, or
other hardware platform, a person having ordinary skill in the art
identifies:
1. The actual hardware and firmware architecture. 2. The supported
processor and device execution interfaces. 3. The device isolation
mechanisms. 4. The available memory protection mechanisms. 5. The
device command queue structure. 6. The command admission and
execution semantics. 7. The supported cancellation and preemption
mechanisms. 8. The available completion and retirement indicators.
9. The trusted computing base. 10. The applicable adversary model.
11. The agent-to-device execution-context binding. 12. The
protected device identity mechanism. 13. The operation classes
requiring authorization. 14. The controlled effectuation boundaries.
15. The relevant alternate command and memory paths. 16. The
Candidate Act descriptor format. 17. The non-effective staging
mechanism. 18. The PED or CIED implementation. 19. The required
authorization predicates. 20. The protected authority-state
representation.
21. The validation-evidence format and commitment ordering. 22. The
scoped capability implementation. 23. The hardware or firmware
Finality Sink. 24. The actual pending command verification
mechanism. 25. The protected capability-consumption semantics. 26.
The authority-generation allocation and update procedure. 27. The
device ownership-generation mechanism. 28. The queue fencing
procedure. 29. The outstanding-command resolution procedure. 30.
The hardware completion-watermark semantics. 31. The IOMMU domain
configuration. 32. The DMA mapping and revocation procedure. 33.
The applicable translation-invalidation semantics. 34. The peer-to-
peer device transfer restrictions. 35. The memory sanitization
procedure. 36. The sanitization coverage-verification procedure. 37.
The memory ownership transition. 38. The device reset and recovery
procedure. 39. The treatment of indeterminate external effects. 40.
The cross-device authority-convergence mechanism. 41. The platform-
specific failure-injection procedures. 42. The actual verification
tests demonstrating the claimed technical properties.
Where the selected hardware lacks a required primitive, the
implementation must disclose a supported equivalent control or narrow
the corresponding guarantee.
A generic statement that a GPU, DPU, FPGA, ASIC, or IOMMU enforces
authorization is not sufficient if the specific enforcement point
requires a property that the chosen hardware cannot establish.
Das Expires 25 April 2027 [Page 241]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.3.197. PART XXIII - TECHNICAL EFFECT
7.3.198. S-8.100 - Technical Effect
this implementation profile provides a hardware-software architecture
in which artificialintelligence computation, device resource
isolation, operation authorization, command admission, hardware
execution, and consequential effectuation can be governed as distinct
technical stages.
A GPU or accelerator may perform permitted computation without
thereby receiving unrestricted authority to transmit outputs, modify
protected resources, access unauthorized memory, or execute
additional device commands.
A PED or CIED may evaluate applicable operation-specific
authorization conditions.
Protected validation evidence and scoped finality authorization may
be established for governed Candidate Acts.
A hardware or firmware Finality Sink may verify the actual pending
command before permitting the designated effect.
Hardware authority generations, protected queue state, IOMMU
controls, DMA restrictions, completion watermarks, and fencing
mechanisms may be used to coordinate restrictions across device
boundaries.
Separate sanitization and ownership-transition mechanisms may prevent
memory associated with an earlier execution context from becoming
accessible to a subsequent unauthorized context.
The claimed technical guarantees depend upon the actual hardware
capabilities and enforcement positions.
7.3.198.1. S-8.101 - Technical Summary
this implementation profile discloses a SmartNIC-, DPU-, GPU-,
accelerator-, and hardwaresoftware-hybrid artificial-intelligence-
agent execution architecture comprising one or more agent execution
contexts, protected device authority, controlled command interfaces,
hardware memory-access restrictions, and effectuation-control
mechanisms.
In a representative protected-finality implementation, an agent-
generated hardware operation is represented as a Candidate Act,
maintained in a Non-Effective State, validated by a PED or CIED,
Das Expires 25 April 2027 [Page 242]
Internet-Draft Kernel-Hardware Execution Finality October 2026
associated with protected validation evidence and scoped non-bearer
finality authorization, and verified by a Finality Sink before its
governed consequential effect.
The embodiment additionally discloses authority-generation-bound
hardware commands, cross-device revocation, device queue fencing,
completion watermarks, DMA mapping restrictions, peer-to-peer
transfer control, and protected recovery.
A further implementation provides device memory ownership transitions
in which prior access is restricted, outstanding commands and memory
accesses are resolved, applicable mappings are invalidated, selected
memory is sanitized, and the sanitization result is verified before
reassignment.
The hardware components may reside within a single processor or
system-on-chip, on peripheral devices, within protected firmware,
across multiple host systems, or within distributed computing
infrastructure.
The disclosure does not require every independently claimed hardware
isolation or memorygovernance invention to employ the complete
protected-finality sequence unless the relevant enforcement point
expressly requires it.
7.3.198.2. PROTECTED INLINE TRANSACTION-FINALITY ENFORCEMENT USING
ATOMIC AUTHORIZATION-STATE TRANSITIONS, NATIVE RESOURCE
7.3.198.3. CONTROL, INTERNALLY COMMITTED VALIDATION EVIDENCE, AND NON-
PORTABLE EXECUTION ENABLEMENT
7.4. Implementation Profile C-09
Source location: original disclosure pages 461-501. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.4.1. C-09.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, database transaction processing, protected authorization,
native resource enforcement, transactional state machines,
concurrency control, and effectuation-boundary security.
More particularly, the embodiment discloses a computer-implemented
method and corresponding system in which a transaction or operation
generated directly or indirectly by an artificial-intelligence agent
Das Expires 25 April 2027 [Page 243]
Internet-Draft Kernel-Hardware Execution Finality October 2026
is retained in a non-effective condition while an inline effectuation
controller performs protected authority validation, updates protected
authorization state, commits an internal validation-state
representation, establishes bounded execution enablement, and
verifies the actual operation before permitting its consequential
effect.
The architecture may operate without generating or transmitting a
separately portable authorization token.
The effectuation controller may perform the applicable authorization
and finality functions within one protected transaction, execution
context, secure resource controller, database engine, protected
kernel path, transaction processor, or equivalent protected
enforcement arrangement.
The embodiment may be implemented in software, firmware, hardware, or
combinations thereof.
7.4.2. C-09.2 - Technical Problem
Artificial-intelligence agents may generate operations through tools,
APIs, database clients, software automation, enterprise applications,
and delegated processes.
Some operations produce consequential effects by modifying native
resource state.
Examples include:
1. Committing a database transaction. 2. Updating an enterprise
account. 3. Changing a protected configuration. 4. Writing a
persistent storage record. 5. Executing a payment-ledger mutation.
6. Activating a cloud resource. 7. Modifying a protected document.
8. Changing resource permissions. 9. Performing a privileged API
operation.
10. Submitting an irreversible command to a controlled subsystem.
Conventional authorization may determine that an identity is
permitted to access the underlying resource.
However, resource-level permission does not necessarily establish
that the particular operation is authorized for an agent's assigned
task, purpose, current policy, or protected resource state.
A further problem arises where authorization and effectuation are
implemented as separate software transactions.
Das Expires 25 April 2027 [Page 244]
Internet-Draft Kernel-Hardware Execution Finality October 2026
For example:
(a) an authorization service approves an operation; (b) the approval
is stored in ordinary application state; (c) the operation is
subsequently submitted to a resource controller; and
(d) the resource controller performs the operation without verifying
that the actual pending operation still corresponds to the approved
transaction.
Such separation may permit stale authorization, operation
substitution, duplicate execution, or time-of-check/time-of-use
inconsistency.
An alternative architecture may issue a portable authorization
artifact to an external executor.
However, a separately portable authorization token is not technically
necessary when protected validation and actual resource effectuation
are controlled by the same transaction processor or by an
appropriately integrated enforcement path.
this implementation profile addresses these problems through inline
protected finality.
7.4.3. C-09.3 - Central Technical Principle
In the representative embodiment:
The same controlled transaction context that verifies the actual
pending operation also determines whether the operation may cross the
protected effectuation boundary.
The authorization may be represented internally by:
| x | A protected transaction-state entry. |
| - | ------------------------------------ |
| x | A protected register. |
| x | A secure transaction latch. |
| x | A protected permission bit. |
| x | A sink-local authorization record. |
| x | A protected write-ahead state transition. |
| - | -------------------------------------------------------- |
| x | An authenticated internal validation entry. |
| x | An equivalent non-portable execution-enabling condition. |
No externally transferable finality token is required.
Das Expires 25 April 2027 [Page 245]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The authorization must nevertheless remain bounded to the actual
operation, current protected state, permitted effectuation scope, and
applicable freshness conditions.
7.4.4. PART I - PRINCIPAL ARCHITECTURE
7.4.5. C-09.4 - Principal Components
A representative system comprises the following components.
7.4.6. Component A - Artificial-Intelligence-Agent Execution
Environment
A process, container, virtual machine, hosted agent runtime, managed
tool environment, or other computational context executing one or
more artificial-intelligence agents.
7.4.7. Component B - Operation Submission Interface
An interface through which the agent requests a transaction or
resource operation.
7.4.8. Component C - Inline Effectuation Controller
A protected controller configured to receive or intercept the
operation and control its actual effectuation.
7.4.9. Component D - Candidate Transaction Holder
A staging mechanism configured to maintain the operation in a non-
effective condition.
7.4.10. Component E - Actual-Operation Descriptor Generator
A mechanism configured to obtain, measure, or reconstruct material
parameters of the operation presented at the effectuation interface.
7.4.11. Component F - Protected Authority-State Store
A protected repository containing applicable task, resource, policy,
revocation, quota, and operation-state information.
7.4.12. Component G - Protected Predicate Evaluator
A component configured to evaluate required machine-verifiable
authorization conditions.
Das Expires 25 April 2027 [Page 246]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.13. Component H - Protected Validation-State Store
A protected component configured to commit validation outcomes and
operation-binding information.
7.4.14. Component I - Inline Enablement Controller
A mechanism configured to establish the bounded execution-enabling
condition required for effectuation.
7.4.15. Component J - Native Resource Controller
A component controlling the database, storage, payment, file, API, or
other selected native resource.
7.4.16. Component K - Protected Consumption Controller
A component configured to transition or consume the required
operation authorization state.
7.4.17. Component L - Transaction Recovery Controller
A mechanism configured to recover or reconcile incomplete
authorization and effectuation operations following interruption or
failure.
The components may be implemented within one database engine,
resource controller, trusted service, protected transaction
processor, secure device, or cooperating protected components.
7.4.18. C-09.5 - Integrated Effectuation Controller
In one implementation, the Inline Effectuation Controller comprises a
native database transaction processor.
The controller performs:
1. Candidate operation staging. 2. Actual operation descriptor
reconstruction. 3. Protected authority-state lookup. 4. Machine-
verifiable predicate evaluation. 5. Protected validation-state
commitment. 6. Bounded execution-enabling state establishment. 7.
Actual-operation correspondence verification. 8. Protected
authorization-state transition. 9. Native resource modification. 10.
Transaction completion or rollback.
Das Expires 25 April 2027 [Page 247]
Internet-Draft Kernel-Hardware Execution Finality October 2026
These functions may execute through one logically protected
transaction without requiring separate physical machines,
cryptographic receipts delivered to the agent, or external
authorization-token exchange.
7.4.19. PART II - OPERATION AND RESOURCE REPRESENTATION
7.4.20. C-09.6 - Candidate Inline Transaction
A Candidate Inline Transaction means a proposed operation presented
to a controlled resource interface but not yet permitted to produce
its specified consequential effect.
The candidate may comprise:
(a) a database update; (b) a protected file modification; (c) a
payment-ledger entry; (d) a cloud resource-state transition; (e) a
protected API operation; (f) a storage commit; (g) a native
application transaction; or (h) another governed operation.
The candidate remains staged until the required protected conditions
are satisfied.
7.4.21. C-09.7 - Candidate Transaction Descriptor
A representative descriptor comprises:
TransactionID = TX-0901
CandidateActID = CA-0901
AgentContextID = AGENT-42
TaskID = TASK-204
OperationClass = UPDATE_RESOURCE
ResourceID = RESOURCE-81
OperationParametersDigest = DIGEST-0901
ExpectedResourceVersion = 17
AuthorityGeneration = 105
RequiredControllerID = CTRL-09
CandidateStatus = STAGED
Das Expires 25 April 2027 [Page 248]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The identifiers are illustrative.
The implementation defines a deterministic encoding of material
operation parameters.
A descriptor may include operation-specific fields such as account
identity, transaction amount, row identity, destination, command
arguments, policy generation, or resource-state precondition.
7.4.22. C-09.8 - Actual-Operation Reconstruction
The Inline Effectuation Controller obtains the operation that would
actually be performed by the native resource mechanism.
For a database update, the controller may reconstruct:
1. The effective database. 2. The target table or resource class.
3. The selected row or object. 4. The proposed modification. 5.
The requesting task context. 6. The current resource version. 7.
The current authority generation. 8. The actual transaction
identity.
The controller compares the actual operation with the permitted
scope.
The operation description is not accepted solely because the
requesting agent supplies a matching authorization label.
7.4.23. C-09.9 - Non-Effective Staging
The Candidate Inline Transaction is retained without producing the
governed effect.
Possible implementations include:
| x | An uncommitted database transaction. |
| - | ------------------------------------ |
| x | A protected transaction object. |
| x | A pending native-resource mutation. |
| x | A disabled resource operation. |
| x | A protected write buffer. |
| x | A withheld API dispatch. |
| - | -------------------------------- |
| x | A secure pending-command record. |
Das Expires 25 April 2027 [Page 249]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The implementation must distinguish a staged resource change from a
change already visible or irreversible outside the controlled
transaction.
A database's uncommitted state is a suitable non-effective
representation for durable commit finality only where the transaction
isolation and visibility rules prevent the claimed externally
effective consequence before commit.
7.4.24. PART III - PROTECTED AUTHORITY STATE
7.4.25. C-09.10 - Protected Authority-State Record
A representative authority record comprises:
AuthorityRecordID = AUTH-0901
AgentContextID = AGENT-42
TaskID = TASK-204
PermittedResource = RESOURCE-81
PermittedOperation = UPDATE_RESOURCE
PolicyGeneration = 105
RevocationGeneration = 27
PermissionScope = SCOPE-A
QuotaRemaining = 3
AuthorityStatus = ACTIVE
The protected authority store is not directly writable by the
requesting agent.
The protection may rely upon operating-system isolation, database
ownership, privileged transaction procedures, cryptographic
integrity, hardware-backed state, or combinations thereof.
7.4.26. C-09.11 - Native Resource Permission
The controller may obtain ordinary resource permissions supplied by
the native resource system.
For example:
Das Expires 25 April 2027 [Page 250]
Internet-Draft Kernel-Hardware Execution Finality October 2026
NativePermission = WRITE
AgentTaskPermission = UPDATE_CONFIG
The controller requires both ordinary permission and operation-
specific protected authorization when the selected policy so
specifies.
Ordinary resource permission remains an input to the authorization
decision rather than a substitute for it.
7.4.27. C-09.12 - Protected Predicate Evaluation
A representative predicate set includes:
P1 - Authenticated execution context.
P2 - Permitted task.
P3 - Authorized operation class.
P4 - Authorized target resource.
P5 - Valid current policy generation.
P6 - Valid revocation state.
P7 - Required resource-state precondition.
P8 - Permitted operation arguments.
P9 - Available protected quota.
P10 - Valid freshness constraint.
P11 - Valid effectuation controller identity.
P12 - Required native resource permission.
The protected authorization result is determined from the predicates
required for the selected operation.
7.4.28. PART IV - INLINE VALIDATION-STATE COMMITMENT
Das Expires 25 April 2027 [Page 251]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.29. C-09.13 - Protected Validation-State Representation
A Protected Validation-State Representation means a machine-
verifiable record or state transition establishing the validation
result and its association with the pending operation.
A representative record comprises:
ValidationStateID = VS-0901
TransactionID = TX-0901
CandidateActID = CA-0901
OperationDescriptorDigest = DIGEST-0901
ValidationOutcome = APPROVED
AuthorityGeneration = 105
ProtectedStateVersion = 302
ControllerID = CTRL-09
EnablementStatus = ELIGIBLE
The record may remain entirely within the protected transaction
engine.
7.4.30. C-09.14 - Internal Commitment Without External Receipt
In one implementation, the validation-state representation is
committed internally through a protected transaction-state mechanism.
The system may use:
1. A sealed internal record. 2. A protected register transition. 3.
A hash-linked state entry. 4. A cryptographic accumulator update. 5.
A protected write-ahead log record. 6. A monotonic state transition.
7. A transactional authorization row. 8. An equivalent protected
state commitment.
The agent need not receive the validation record.
The Finality Sink need not receive a separately transmitted external
receipt if the required state is already available within the
protected transaction.
Das Expires 25 April 2027 [Page 252]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Absence of an external receipt does not remove the requirement to
commit the protected validation state.
7.4.31. C-09.15 - Commitment Ordering
A representative logical sequence comprises:
VALIDATE ACTUAL OPERATION
↓
ESTABLISH PROTECTED VALIDATION STATE
↓
COMMIT VALIDATION STATE BEFORE OR ATOMICALLY WITH ENABLEMENT
↓
ESTABLISH BOUNDED INLINE ENABLEMENT
↓
VERIFY CURRENT PENDING OPERATION
↓
PERMIT EFFECTUATION
In a transactionally integrated implementation, the validation record
and resource mutation may become durable through one atomic commit.
Before that commit, neither is externally committed.
The controller's internal protected state machine ensures that
resource modification cannot commit unless the corresponding
validation-state conditions are included in the successful
transaction.
7.4.32. PART V - NON-PORTABLE INLINE ENABLEMENT
7.4.33. C-09.16 - Bounded Execution-Enabling Condition
A Bounded Execution-Enabling Condition means a protected state or
control condition that permits a specified operation only within the
applicable protected effectuation scope.
A representative condition comprises:
Das Expires 25 April 2027 [Page 253]
Internet-Draft Kernel-Hardware Execution Finality October 2026
EnablementID = EN-0901
TransactionID = TX-0901
DescriptorDigest = DIGEST-0901
ControllerID = CTRL-09
PermittedResource = RESOURCE-81
AuthorityGeneration = 105
ProtectedStateVersion = 302
UsageStatus = UNUSED
The condition is maintained internally by the effectuation controller
or another appropriately protected component.
7.4.34. C-09.17 - Non-Portable Authority
The bounded enablement does not need to be represented by a
separately transferable bearer or non-bearer authorization token.
For example, the controller may associate authorization with:
(a) a protected transaction identifier; (b) a private state-machine
entry; (c) a transaction-local latch; (d) a protected register; (e)
an internal permission state; (f) a protected operation slot; or (g)
a sink-local authorization record.
The requesting agent cannot independently apply that condition to a
different operation or resource.
An ordinary transaction identifier communicated to the agent does not
itself grant execution authority.
7.4.35. C-09.18 - Transaction-Local Enablement
In one implementation, the bounded enablement exists only within the
protected transaction executing the actual operation.
The enablement is invalidated when:
Das Expires 25 April 2027 [Page 254]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. The transaction commits. 2. The transaction aborts. 3. The
operation changes materially. 4. Required authority is revoked. 5.
A protected state precondition becomes invalid. 6. A required
freshness condition expires. 7. The controller encounters an
unrecoverable validation failure.
A subsequent operation requires a corresponding permitted
authorization transition.
7.4.36. PART VI - ATOMIC CONSUMPTION AND EFFECTUATION
7.4.37. C-09.19 - Atomic Authorization Consumption
A protected authorization state may have the following logical
states:
AVAILABLE
RESERVED
CONSUMED
DENIED
REVOKED
EXPIRED
The effectuation controller prevents unauthorized reuse of
authorization already consumed by another operation.
In a native transactional implementation, the authorization-state
transition and resource mutation can be included in the same atomic
transaction.
7.4.38. C-09.20 - Database Atomicity
Consider a protected database containing:
AuthorityState
ValidationState
ResourceState
The controller may use one transaction to:
Das Expires 25 April 2027 [Page 255]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Lock or otherwise protect the required authority-state version.
2. Reconstruct the actual proposed resource mutation. 3. Evaluate
current authorization. 4. Insert the protected validation-state
entry. 5. Update or consume the authorization state. 6. Perform the
resource mutation. 7. Commit all required changes atomically.
If a required operation fails, the transaction rolls back.
No durable resource mutation becomes committed without the required
protected validation state.
7.4.39. C-09.21 - Native Resource Transaction Boundary
In one implementation:
Protected authorization-state commitment and native resource
modification belong to the same atomic transactional boundary.
The controller may use serializable execution, transactional row
locks, compare-and-update semantics, or another native concurrency-
control mechanism.
The implementation must ensure that an authorization consumed for one
operation cannot be concurrently consumed for an unauthorized
duplicate operation.
7.4.40. C-09.22 - Atomicity Limitation
Atomicity across independent external services is not assumed.
For example, a database transaction cannot ordinarily guarantee
atomic commitment of both:
(a) a local authorization-state update; and (b) an independent remote
payment or HTTP request
unless the external system participates in an appropriate common
transaction protocol or the architecture controls a suitable
equivalent effectuation boundary.
Where such atomicity is unavailable, the embodiment may use an
operation registry, reservation state, durable outbox, external
idempotency control, or reconciliation procedure.
Those mechanisms provide defined delivery and recovery semantics but
must not be described as universal exactly-once external
effectuation.
Das Expires 25 April 2027 [Page 256]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.41. PART VII - PROTECTED CACHED AUTHORIZATION
7.4.42. C-09.23 - Cached Authorization State
A previously evaluated authorization result may be stored in
protected cache state.
A representative cache record comprises:
CacheEntryID = CACHE-0901
AgentContextID = AGENT-42
AuthorizedOperationClass = UPDATE_RESOURCE
PermittedResourceScope = SCOPE-A
PolicyGeneration = 105
RevocationGeneration = 27
ExpiryCondition = TIME-BOUND
CacheStatus = ACTIVE
The cached record may accelerate repeated predicate evaluation.
7.4.43. C-09.24 - Cache as Intermediate Authority Input
A cached authorization result is not unconditional authority to
perform arbitrary operations.
Before effectuation, the Inline Effectuation Controller verifies:
(a) actual operation binding; (b) permitted resource scope; (c)
current policy state; (d) current revocation state; (e) applicable
freshness; (f) protected-state validity; and
(g) required usage limits.
If a cached result is insufficient, stale, or inconsistent with the
pending operation, the controller performs fresh validation or denies
the operation.
7.4.44. C-09.25 - Cache Generation Invalidation
A change in protected policy or revocation generation may invalidate
affected cache entries.
Das Expires 25 April 2027 [Page 257]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The implementation may use:
1. Generation comparison. 2. Explicit cache revocation. 3.
Protected expiry. 4. Protected invalidation tables. 5. Current
authority-state lookup. 6. A combination of these mechanisms.
The cache is not permitted to override a current mandatory protected
restriction merely because the earlier cached result remains
cryptographically valid.
7.4.45. PART VIII - TRANSACTION-LOCAL DENIAL EVIDENCE
7.4.46. C-09.26 - Protected Denial State
When a required validation condition fails, the controller may create
a protected denial-state representation.
A representative record comprises:
DenialRecordID = DENY-0901
CandidateActID = CA-0901
OperationDescriptorDigest = DIGEST-0901
AuthorityGeneration = 105
DenialReasonClass = RESOURCE_SCOPE_MISMATCH
DenialGeneration = 481
RetryPolicy = NEW_VALIDATION_REQUIRED
DenialStatus = ACTIVE
The record may be maintained in protected transactional storage.
7.4.47. C-09.27 - Denial Commitment
A protected denial record may be committed when:
1. An authorization predicate fails. 2. The actual operation
differs from the authorized descriptor. 3. The required authority
has been revoked. 4. The operation is stale. 5. Required protected
evidence is invalid. 6. A replay attempt is detected. 7. A required
resource-state precondition fails. 8. A prohibited rollback is
detected.
Das Expires 25 April 2027 [Page 258]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The denial record may reference the applicable operation identity,
generation, and restriction.
7.4.48. C-09.28 - Denial and Retry Control
A denied Candidate Act may not automatically regain authorization by
repeating the same operation identifier.
In one implementation, a protected operation registry records a
terminal denial state.
A subsequent attempt must use a new authorized validation transition
satisfying current policy.
The system must distinguish:
(a) retrying the same denied operation without new authorization; and
(b) submitting a legitimate new Candidate Act after required
conditions have changed.
The denial mechanism prevents unauthorized reuse without necessarily
prohibiting every future independently authorized operation.
7.4.49. C-09.29 - Durable Denial Following Transaction Rollback
A failed business transaction may require its resource changes to
roll back while retaining durable evidence of the denial.
In one implementation, the controller:
1. Detects validation failure.
2. Aborts the resource transaction. 3. Creates a protected denial
record in a separate authorized protected-state transaction. 4.
Binds the denial record to the original Candidate Act identity and
relevant generation. 5. Prevents subsequent execution of the denied
Candidate Act without fresh authorization.
The protected operation registry uses a unique Candidate Act identity
or equivalent mechanism to prevent conflicting concurrent retries
during this process.
This ordering distinguishes rollback of uncommitted business effects
from durable recording of the authorization failure.
Das Expires 25 April 2027 [Page 259]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.50. PART IX - COMPLETE INLINE EXECUTION WORKFLOW
7.4.51. C-09.30 - Principal 25-Step Workflow
7.4.52. Step C9-01 - Agent operation proposal
The artificial-intelligence agent generates a proposed native
resource operation.
7.4.53. Step C9-02 - Controlled interface reception
The operation reaches the Inline Effectuation Controller.
7.4.54. Step C9-03 - Candidate Act identification
A unique Candidate Act identity is established.
7.4.55. Step C9-04 - Non-effective staging
The operation is retained without producing the governed consequence.
7.4.56. Step C9-05 - Protected transaction initiation
The controller establishes the applicable protected transactional
context.
7.4.57. Step C9-06 - Actual-operation reconstruction
The controller obtains the actual resource, operation class, and
material parameters.
7.4.58. Step C9-07 - Descriptor canonicalization
The operation is represented using a deterministic descriptor.
7.4.59. Step C9-08 - Authenticated context association
The agent, task, and relevant execution identity are associated with
the operation.
7.4.60. Step C9-09 - Native permission retrieval
The controller obtains relevant ordinary resource permissions.
7.4.61. Step C9-10 - Protected authority-state acquisition
The controller obtains current task, policy, revocation, and usage
state.
Das Expires 25 April 2027 [Page 260]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.62. Step C9-11 - Resource-state protection
The required resource-state version is locked or protected through
the selected concurrency mechanism.
7.4.63. Step C9-12 - Predicate evaluation
The controller evaluates mandatory authority predicates.
7.4.64. Step C9-13 - Protected-state operation
The controller performs the required reservation, version, quota, or
other protected-state operation.
7.4.65. Step C9-14 - Validation-state construction
The controller creates the internal machine-verifiable validation-
state representation.
7.4.66. Step C9-15 - Validation-state commitment
The protected validation state is committed before or atomically with
the permitted effectuation transition.
7.4.67. Step C9-16 - Inline bounded enablement
The controller establishes the non-portable execution-enabling
condition.
7.4.68. Step C9-17 - Current-operation re-acquisition
Where required, the controller obtains the actual pending operation
again.
7.4.69. Step C9-18 - Operation-binding verification
The controller verifies correspondence between the actual pending
operation and validated descriptor.
7.4.70. Step C9-19 - Protected-state verification
Current protected authority and usage conditions are checked.
7.4.71. Step C9-20 - Enablement verification
The bounded enablement is verified against the intended controller,
scope, and applicable freshness.
Das Expires 25 April 2027 [Page 261]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.72. Step C9-21 - Atomic authorization consumption
The protected authorization state is transitioned according to the
selected usage policy.
7.4.73. Step C9-22 - Native resource mutation
The corresponding native resource operation is performed.
7.4.74. Step C9-23 - Atomic commit
The required authorization-state and resource-state changes are
committed under the selected transactional semantics.
7.4.75. Step C9-24 - Outcome recording
The controller records completion or failure state.
7.4.76. Step C9-25 - Enablement invalidation
The bounded transaction-local enablement is consumed or disabled
against unauthorized subsequent use.
7.4.77. PART X - REFERENCE IMPLEMENTATION ALGORITHMS
C-09.31 - Algorithm A: Protected Inline Native-Resource Transaction
function ExecuteInlineFinality(candidate):
context = AuthenticateRequestOrigin(candidate)
if context is invalid:
return DENIED
begin serializable_transaction
if not ReserveUniqueCandidateIdentity(candidate.id):
rollback return DENIED_OR_EXISTING_STATUS
actual = ReconstructNativeOperation(candidate)
if actual is invalid:
rollback CommitProtectedDenialSeparately(candidate) return DENIED
descriptor = Canonicalize(actual, context)
Das Expires 25 April 2027 [Page 262]
Internet-Draft Kernel-Hardware Execution Finality October 2026
authority = ReadAndLockProtectedAuthority(
context, descriptor )
resource = ReadAndLockTargetResource(
descriptor.resource_id )
if not VerifyNativeResourcePermission(
context, resource, actual ):
rollback CommitProtectedDenialSeparately(candidate) return DENIED if
not EvaluateRequiredAuthorityPredicates(
descriptor, authority, resource ):
rollback CommitProtectedDenialSeparately(candidate) return DENIED
validation = InsertProtectedValidationState({
candidate_id: candidate.id, descriptor_digest:
HashCanonical(descriptor), authority_generation:
authority.generation, resource_version: resource.version,
validation_result: APPROVED })
if validation is invalid:
rollback return DENIED enablement =
EstablishTransactionLocalEnablement(
candidate.id, validation, descriptor )
if not VerifyActualPendingOperation(
actual,
descriptor, enablement ):
rollback CommitProtectedDenialSeparately(candidate) return DENIED
if not ConsumeAuthorizationState(
authority, enablement ):
rollback return DENIED
ApplyNativeResourceMutation(resource, actual)
Das Expires 25 April 2027 [Page 263]
Internet-Draft Kernel-Hardware Execution Finality October 2026
MarkCandidateCompleted(candidate.id)
commit serializable_transaction
return COMMITTED
In a concrete implementation, candidate reservation must be durable
or otherwise coordinated with denial recording so that a failed
transaction cannot race with an unauthorized duplicate submission.
The selected resource engine must actually provide the required
isolation and atomic-commit guarantees.
C-09.32 - Algorithm B: Non-Portable Inline Enablement
function EstablishTransactionLocalEnablement(
candidate_id, validation, descriptor ):
if validation.result != APPROVED:
return DENIED if not IsCurrentProtectedTransaction():
return DENIED
enablement = ProtectedTransactionState.create({
candidate_id: candidate_id, descriptor_digest:
HashCanonical(descriptor), validation_state_id: validation.id,
controller_id: CurrentControllerID(),
resource_scope: descriptor.resource_scope, authority_generation:
validation.authority_generation, usage_state: UNUSED })
return enablement
The enablement need not be exported as a token.
It remains meaningful only within the applicable protected
transaction or controller-local authorization state.
C-09.33 - Algorithm C: Atomic Authorization Consumption
function ConsumeAuthorizationState(authority, enablement):
if enablement.usage_state != UNUSED:
return DENIED
Das Expires 25 April 2027 [Page 264]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if enablement.controller_id != CurrentControllerID():
return DENIED
if authority.generation != enablement.authority_generation:
return DENIED
if not VerifyCurrentRevocationState(authority):
return DENIED
if not VerifyProtectedValidationBinding(enablement):
return DENIED
if not TransactionalCompareAndUpdate(
enablement.usage_state, UNUSED, CONSUMED ):
return DENIED
return CONSUMED
The usage transition participates in the same protected transactional
context as the governed resource effect where native atomicity is
claimed.
C-09.34 - Algorithm D: Protected Cache Revalidation
function ValidateCachedAuthorization(
cache_entry, actual_operation ):
if cache_entry is unavailable:
return CACHE_MISS
if not VerifyProtectedCacheIntegrity(cache_entry):
return CACHE_INVALID if not MatchOperationScope(
actual_operation, cache_entry ):
return CACHE_INVALID
current = ReadCurrentProtectedAuthorityState(
Das Expires 25 April 2027 [Page 265]
Internet-Draft Kernel-Hardware Execution Finality October 2026
actual_operation )
if current.policy_generation != cache_entry.policy_generation:
return CACHE_INVALID if current.revocation_generation !=
cache_entry.revocation_generation:
return CACHE_INVALID if not VerifyFreshness(cache_entry):
return CACHE_INVALID
if not VerifyCurrentUsageConditions(
current, actual_operation ):
return CACHE_INVALID
return VALID_INTERMEDIATE_AUTHORIZATION
The cached result supplies an intermediate input.
Actual effectuation still requires the protected inline transaction
and its current-operation verification.
7.4.78. C-09.35 - Algorithm E: Transaction-Local Denial
function CommitProtectedDenialSeparately(candidate):
begin protected_denial_transaction
existing = ProtectedOperationRegistry.lookup(
candidate.id )
if existing.status == COMPLETED:
rollback return ALREADY_EFFECTUATED if existing.status == DENIED:
rollback return ALREADY_DENIED
if not VerifyCandidateStillDeniable(existing):
rollback return RECONCILIATION_REQUIRED
InsertOrUpdateProtectedDenial({
Das Expires 25 April 2027 [Page 266]
Internet-Draft Kernel-Hardware Execution Finality October 2026
candidate_id: candidate.id, descriptor_digest:
candidate.descriptor_digest, authority_generation:
CurrentAuthorityGeneration(), denial_status: DENIED, retry_policy:
NEW_VALIDATION_REQUIRED })
commit protected_denial_transaction
return DENIAL_COMMITTED
The implementation must use appropriate candidate-state serialization
to prevent the denial transaction from conflicting with another
transaction that has already committed an authorized effect.
7.4.79. C-09.36 - Algorithm F: Transaction Recovery
function RecoverInlineFinalityState():
RecoverNativeTransactionalStorage()
operations = LoadIncompleteCandidateOperations()
for each operation in operations:
if operation.status == COMPLETED:
continue
if operation.status == DENIED:
PreserveDenialRestrictions(operation) continue
if operation.status == STAGED:
RequireFreshProtectedValidation(operation) continue
if operation.status == INDETERMINATE:
ReconcileAgainstAuthoritativeResourceState(
operation )
VerifyProtectedAuthorityGenerations()
VerifyAuthorizationConsumptionState()
return EvaluateRecoveryStatus()
Das Expires 25 April 2027 [Page 267]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A native database recovery mechanism may provide authoritative
evidence of transaction commit or rollback.
For external operations outside its atomic transactional boundary,
additional reconciliation mechanisms may be necessary.
7.4.80. PART XI - WORKED TECHNICAL EXAMPLES
C-09.37 - Example A: Atomic Enterprise Database Update
The following is a hypothetical implementation example.
An AI agent is authorized to modify a designated configuration
record.
The agent proposes an update.
The resource controller receives the request.
The controller opens a protected native database transaction.
It identifies the actual target row.
It verifies ordinary database permission and task-specific
authorization.
It checks the current policy generation and expected row version.
It creates an internal protected validation-state entry.
A transaction-local enablement is established.
The controller verifies the actual update parameters.
The authorization state is consumed.
The configuration record is updated.
The transaction commits the authorization-state and resource-state
changes atomically.
The same authorization cannot be used for another modification
without a fresh permitted transition.
C-09.38 - Example B: Concurrent Duplicate Operation
Two agent workers attempt the same protected database modification
using the same Candidate Act identity.
Das Expires 25 April 2027 [Page 268]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Worker A acquires the required protected operation-state lock.
Worker B attempts a conflicting operation.
Worker A validates and commits the authorized modification.
The protected operation state transitions to COMPLETED.
Worker B observes the committed state or encounters a transaction
conflict requiring retry.
Worker B cannot commit another resource mutation under the already
consumed Candidate Act authority.
This implementation may use a unique Candidate Act constraint,
transactional compare-andupdate, serializable isolation, or
equivalent supported mechanism.
C-09.39 - Example C: Cached Authorization After Revocation
An agent previously received authorization to update a permitted
enterprise resource.
The corresponding result is stored in protected cache state.
A security controller subsequently revokes the relevant authority.
The protected revocation generation advances.
The agent proposes another operation.
The Inline Effectuation Controller retrieves the cached
authorization.
The controller compares the cached generation with current protected
authority state.
The cache entry is invalid.
The proposed operation is withheld.
The earlier cached approval does not independently authorize the new
effect.
C-09.40 - Example D: Atomic Payment-Ledger Mutation
An AI agent proposes a payment-related ledger update.
Das Expires 25 April 2027 [Page 269]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The transaction processor stages the operation.
The processor validates the intended payer, beneficiary, amount,
transaction scope, and applicable protected authority.
It creates an internal protected validation-state entry.
The processor establishes bounded transaction-local enablement.
It verifies that the actual ledger mutation corresponds to the
validated operation.
It consumes the required authorization and commits the ledger-state
transition in one native transaction.
Where actual interbank settlement occurs later through a separate
external system, the embodiment does not enforcement point that local
ledger atomicity automatically provides atomicity of remote
settlement.
A separate finality or reconciliation mechanism may govern that
downstream effect.
7.4.81. C-09.41 - Example E: Protected File Commit
An agent prepares a modified configuration file.
The modification is staged in a protected temporary representation.
The file controller obtains the actual target resource and content
digest.
The protected authorization predicates are evaluated.
A validation-state record is committed.
The controller establishes bounded enablement.
The actual pending file modification is verified.
The resource modification is committed through an applicable
protected filesystem or transactional storage mechanism.
If the file system lacks an atomic multi-object transaction covering
the relevant authorization state and file content, the implementation
must use a suitable journaled recovery procedure or limit the claimed
atomic guarantee accordingly.
Das Expires 25 April 2027 [Page 270]
Internet-Draft Kernel-Hardware Execution Finality October 2026
C-09.42 - Example F: Transaction-Local Denial After Operation
Substitution
An agent requests modification of Resource A.
The protected validation procedure approves the permitted operation
for Resource A.
Before effectuation, the actual pending operation is found to target
Resource B.
The controller detects a descriptor mismatch.
The resource transaction is aborted.
A protected denial-state record is committed for the invalid
Candidate Act.
A later retry using the same stale Candidate Act identity is refused.
A new independently authorized Candidate Act is required before any
permitted modification of Resource B.
7.4.82. PART XII - FAILURE AND ADVERSARIAL SCENARIOS
7.4.83. C-09.43 - Representative Failure Conditions
7.4.84. F1 - Missing Protected Validation State
The effectuation controller cannot establish the required protected
validation representation.
Effectuation is withheld.
7.4.85. F2 - Invalid Operation Binding
The actual resource operation differs from the validated descriptor.
Effectuation is denied.
7.4.86. F3 - Stale Policy Generation
The authorization references an unacceptable policy generation.
The current operation is revalidated or denied.
Das Expires 25 April 2027 [Page 271]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.87. F4 - Revoked Authority
The required protected authority is revoked before effectuation.
The controller withholds the operation.
7.4.88. F5 - Expired Enablement
The transaction-local enablement no longer satisfies the applicable
freshness condition.
Effectuation is denied.
7.4.89. F6 - Wrong Controller
An enablement associated with one controller is presented to another
controller.
The protected controller binding prevents unauthorized use.
7.4.90. F7 - Wrong Resource
The proposed resource identity differs from the authorized resource.
The resource operation is denied.
7.4.91. F8 - Concurrent Consumption
Two transactions attempt to consume the same bounded authorization.
The required transactional isolation or atomic state transition
prevents unauthorized duplicate consumption.
7.4.92. F9 - Native Resource Permission Failure
The ordinary resource permission check fails.
Protected operation-specific authorization does not override that
required native restriction.
7.4.93. F10 - Cached Authorization Stale
A cached result no longer matches current policy or revocation state.
The cached result is rejected.
Das Expires 25 April 2027 [Page 272]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.94. F11 - Cache Scope Expansion
A cached permission for a limited resource is applied to a broader
operation.
Current-operation scope verification rejects the expansion.
7.4.95. F12 - Transaction Crash Before Commit
A transaction fails before the required commit.
The transactional storage mechanism rolls back uncommitted resource
changes and corresponding authorization-state changes.
7.4.96. F13 - Crash After Commit
A transaction commits but the agent does not receive confirmation.
The recovery mechanism consults authoritative committed operation
state rather than blindly repeating the effect.
7.4.97. F14 - Validation-State Tampering
The agent attempts to modify protected validation state.
The protected-state boundary prevents unauthorized modification
according to the selected threat model.
7.4.98. F15 - Denial-State Rollback
An attacker attempts to restore an earlier state lacking a committed
denial or revocation.
The applicable protected continuity or transactional recovery
mechanism prevents prohibited stale authority from becoming
effective.
7.4.99. F16 - Candidate Identity Reuse
An agent reuses an earlier Candidate Act identifier.
The protected operation registry detects conflicting or terminal
state.
7.4.100. F17 - Resource Version Conflict
The resource changes after a prior read.
Das Expires 25 April 2027 [Page 273]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The required version or isolation predicate prevents commitment based
on stale resource assumptions.
7.4.101. F18 - Transaction Deadlock
The native resource engine detects a deadlock.
The transaction aborts according to its concurrency protocol.
A retry must satisfy the applicable current authorization conditions.
7.4.102. F19 - Protected-State Store Unavailable
The required protected authority or validation-state store is
unavailable.
The governed operation remains non-effective.
7.4.103. F20 - Authorization Failure Followed by Retry
The controller commits protected denial state.
A subsequent retry cannot bypass the denial by reusing the invalid
Candidate Act.
7.4.104. F21 - Uncontrolled Native Resource Path
An agent possesses an alternative route for modifying the same
governed resource without the Inline Effectuation Controller.
The implementation must restrict or mediate that path to establish
non-bypassable finality.
7.4.105. F22 - Remote Effect Outside Atomic Boundary
A local transaction triggers a remote operation that cannot
participate in the native commit.
The system distinguishes locally atomic state changes from
independently executed remote consequences.
7.4.106. F23 - Protected Counter or Quota Exhaustion
A required quota is exhausted.
The authorization predicate fails.
Das Expires 25 April 2027 [Page 274]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.107. F24 - Resource Snapshot Restoration
An earlier resource snapshot is restored.
The system applies the necessary protected generation and state-
continuity checks to prevent prohibited authority reuse.
7.4.108. PART XIII - IMPLEMENTATION VARIATIONS
7.4.109. C-09.44 - Native Database Implementation
The protected controller resides in a database engine, trusted stored
procedure, transaction service, or equivalent resource mechanism.
Authorization-state changes and resource mutations may share one
native transaction.
7.4.110. C-09.45 - Payment-Switch Implementation
A payment switch or transaction processor controls a defined payment
authorization or ledger-effectuation boundary.
Protected authorization and bounded enablement are implemented within
the applicable transaction-processing context.
External settlement boundaries remain subject to their own actual
control mechanisms.
| C-09.46 - Filesystem Implementation A protected file-operation controller stages modifications and verifies them before protected commitment. The atomicity guarantee is limited to operations and state covered by the selected filesystem or transaction mechanism. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-09.47 - Cloud Resource-Controller Implementation An agent requests a cloud resource change. A protected native resource controller validates the operation, maintains internal authorization state, and controls the corresponding resource transition. Where the actual change occurs through another independently operated system, the claimed boundary must be identified accordingly. |
| C-09.48 - Kernel-Mediated Implementation An applicable kernel enforcement component controls a selected resource operation. The kernel or associated protected resource controller establishes the required inline authority conditions. The security model depends on the protection provided by the selected operating system and enforcement mechanism. |
7.4.111. C-09.49 - TEE-Assisted Implementation
A TEE maintains required protected authority or validation state.
A controlled effectuation interface uses bounded authorization
established by the TEE.
The implementation must preserve the required relationship between
protected validation and actual resource effectuation.
| C-09.50 - Hardware Transaction-Controller Implementation A protected controller implements validation-state transition, bounded enablement, and command release through hardware or firmware state machines. A protected register or latch may represent the non-portable enablement condition. The selected device must provide the claimed ordering and state properties. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-09.51 - Single-Process Protected Transaction One appropriately protected process may implement the complete finality sequence. No separately portable capability, physical PED server, or external receipt exchange is required. The required logical operations remain identifiable. |
| C-09.52 - Distributed Transactional Implementation Multiple protected components may coordinate a common transactional authorization and effectuation procedure. An actual common atomic commit requires a suitable distributed transaction protocol or equivalent mechanism implemented by the participating resource controllers. A conventional RPC authorization call followed by an unrelated external operation does not by itself provide the same atomicity. |
Das Expires 25 April 2027 [Page 275]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.112. PART XIV - REPRESENTATIVE DATA STRUCTURES
7.4.113. C-09.53 - CandidateInlineTransactionRecord
Fields may include:
1. CandidateActID. 2. TransactionID.
3. AgentContextID. 4. TaskID. 5. OperationClass. 6. ResourceID.
7. OperationDescriptorDigest. 8. AuthorityGeneration. 9.
CandidateStatus. 10. TransactionReference.
7.4.114. C-09.54 - ProtectedAuthorityRecord
Fields may include:
1. AuthorityRecordID. 2. AuthorizedAgentOrTask. 3.
PermittedOperationClasses. 4. PermittedResources. 5.
PolicyGeneration. 6. RevocationGeneration. 7. ProtectedQuotaState.
8. AuthorityStatus. 9. StateVersion.
7.4.115. C-09.55 - InlineValidationStateRecord
Fields may include:
1. ValidationStateID. 2. CandidateActID. 3. TransactionID. 4.
DescriptorDigest. 5. ValidationOutcome. 6. AuthorityGeneration. 7.
ProtectedStateVersion. 8. ControllerID. 9. CommitmentStatus.
7.4.116. C-09.56 - InlineEnablementRecord
Fields may include:
1. EnablementID. 2. CandidateActID. 3. TransactionID.
4. 5. 6. 7. 8. 9.
DescriptorDigest. ControllerID. PermittedEffectuationScope.
AuthorityGeneration. FreshnessReference. UsageState.
7.4.117. C-09.57 - NativeResourceStateRecord
Fields may include:
1. ResourceID. 2. ResourceClass. 3. CurrentResourceVersion. 4.
CurrentProtectedOperationState. 5. NativePermissionReference. 6.
LastCommittedTransactionID. 7. LastAppliedAuthorityGeneration.
Das Expires 25 April 2027 [Page 276]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.4.118. C-09.58 - ProtectedCacheRecord
Fields may include:
1. CacheEntryID. 2. AgentContextID. 3. AuthorizedOperationClass.
4. PermittedResourceScope. 5. PolicyGeneration. 6.
RevocationGeneration. 7. ExpiryCondition. 8. CacheStatus.
7.4.119. C-09.59 - ProtectedDenialRecord
Fields may include:
1. 2. 3. 4. 5. 6. 7. 8.
DenialRecordID. CandidateActID. DescriptorDigest.
DenialReasonClass. AuthorityGeneration. DenialGeneration.
RetryPolicy. DenialStatus.
7.4.120. C-09.60 - TransactionRecoveryRecord
Fields may include:
1. TransactionID. 2. CandidateActID. 3.
LastProtectedStateTransition. 4. ValidationCommitmentReference. 5.
AuthorizationConsumptionState. 6. NativeResourceCommitStatus. 7.
ExternalOperationReference. 8. RecoveryStatus.
These records may be realized through database rows, protected
memory, write-ahead records, secure registers, protected transaction
logs, or authenticated storage.
7.4.121. PART XV - PROPOSED VERIFICATION TESTS
7.4.122. C-09.61 - Engineering Test Matrix
The following tests are proposed rather than completed experiments.
7.4.123. Test Condition
T1 Authorized native resource transaction T2 Unauthorized operation
T3 Missing validation-state commitment T4 Missing bounded enablement
T5 Altered actual operation T6 Concurrent duplicate operation T7
Replayed consumed authorization T8 Native resource permission missing
T9 Stale policy generation T10 Cached authorization after revocation
T11 Cache used outside permitted scope T12 Transaction crash before
commit T13 Crash after successful commit T14 Resource-version
conflict T15 Denial-state commitment T16 Candidate identifier reuse
T17 Protected-state rollback attempt T18 Controller identity mismatch
Das Expires 25 April 2027 [Page 277]
Internet-Draft Kernel-Hardware Execution Finality October 2026
T19 Protected authority-store failure
7.4.124. Expected result
Commit permitted Denied Effect withheld Effect withheld Mismatch
rejected No unauthorized duplicate commit Rejected Commit denied
Revalidated or denied Cache invalidated Rejected Atomic rollback
Completion recovered Conflicting commit prevented Invalid operation
remains blocked Conflicting reuse rejected Required continuity
enforced Enablement rejected No permissive fallback
T20 Protected quota exhaustion T21 External operation outside native
transaction T22 Resource transaction deadlock T23 Invalid internally
committed evidence T24 No external receipt transmitted
Operation denied Boundary limitation recognized Required rollback or
retry procedure Effect denied Internal required commitment still
enforced
The test harness must establish the actual native transaction
boundaries and protected-state guarantees supported by the selected
resource engine.
7.4.125. PART XVI - Enforcement-Point Mapping and Technical
Correspondence
7.4.126. C-09.62 - Independent enforcement point(s) 9
this implementation profile supports the proposed method through:
(a) the Operation Submission Interface; (b) Candidate Inline
Transaction staging; (c) actual-operation reconstruction; (d)
protected predicate evaluation; (e) protected authority-state
operations; (f) internal validation-state commitment; (g) non-
portable transaction-local enablement; (h) current-operation, scope,
state, freshness, and controller verification; (i) controlled native
effectuation; and (j) denial or withholding upon failure.
The embodiment does not require an independently portable capability
or externally disclosed validation receipt.
7.4.127. C-09.63 - Dependent enforcement point(s) 10
Atomic commit and consumption are addressed through:
x Protected authorization-state transitions.
Das Expires 25 April 2027 [Page 278]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Native transactional resource mutation. |
| - | --------------------------------------- |
| x | Transaction isolation. |
| x | Concurrent consumption control. |
| x | Rollback and recovery. |
| x | Prevention of duplicate effectuation. |
A enforcement point requiring atomicity must be limited to an
actually atomic enforcement boundary.
7.4.128. C-09.64 - Dependent enforcement point(s) 11
Native resource enforcement is addressed through:
| x | Database transaction processors. |
| - | -------------------------------------- |
| x | Storage commit controllers. |
| x | Payment-ledger controllers. |
| x | File-operation controllers. |
| x | Cloud resource controllers. |
| x | Native permission checks. |
| x | Protected operation-specific finality. |
The examples distinguish native resource permission from independent
task-specific authorization.
7.4.129. C-09.65 - Dependent enforcement point(s) 12
Evidence commitment without external receipt release is addressed
through:
| x | Internal protected validation records. |
| - | -------------------------------------- |
| x | Protected register transitions. |
| x | Hash-linked state. |
| x | Write-ahead commitments. |
| x | Protected transactional entries. |
| x | Transaction-local validation state. |
The absence of externally delivered evidence does not bypass the
required internal commitment.
7.4.130. C-09.66 - Dependent enforcement point(s) 13
Protected cached authorization is addressed through:
Das Expires 25 April 2027 [Page 279]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| x | Protected cache entries. |
| - | ------------------------------- |
| x | Operation-specific cache scope. |
| x | Policy-generation checks. |
| x | Revocation-generation checks. |
| - | ---------------------------------------- |
| x | Freshness validation. |
| x | Current resource and usage verification. |
Cached authorization remains an intermediate input.
7.4.131. C-09.67 - Dependent enforcement point(s) 14
Transaction-local denial evidence is addressed through:
| x | Protected denial records. |
| - | ------------------------------------------------------- |
| x | Candidate-specific terminal states. |
| x | Protected retry policy. |
| x | Revocation and mismatch records. |
| x | Durable denial following business transaction rollback. |
| x | Prevention of stale Candidate Act reuse. |
The implementation supports legitimate new authorization while
preventing unauthorized replay of invalid prior state.
7.4.132. PART XVII - IMPLEMENTATION REQUIREMENTS
7.4.133. C-09.68 - implementer Implementation Checklist
A person having ordinary skill in the art implementing the embodiment
identifies:
1. The native resource controller. 2. The actual effectuation
boundary. 3. The trusted computing base. 4. The agent-origin
authentication mechanism. 5. The Candidate Act identifier. 6. The
actual-operation descriptor format. 7. The staging mechanism. 8.
The protected authority-state store. 9. The required predicates. 10.
The native resource-permission interface. 11. The current resource-
state preconditions. 12. The protected validation-state
representation. 13. The commitment ordering. 14. The non-portable
enablement mechanism. 15. The current-operation verification
procedure. 16. The protected consumption transition. 17. The native
resource mutation operation. 18. The transactional atomicity
guarantee. 19. The concurrency-control mechanism. 20. The protected
cache policy.
Das Expires 25 April 2027 [Page 280]
Internet-Draft Kernel-Hardware Execution Finality October 2026
21. The cache invalidation procedure. 22. The denial-state
commitment procedure. 23. The retry and duplicate-operation
restrictions. 24. The crash-recovery mechanism. 25. The treatment
of external effects outside the atomic boundary. 26. The
verification procedures demonstrating the required security
properties.
The selected implementation must provide concrete technical
mechanisms for each feature.
7.4.134. C-09.69 - Technical Effect
this implementation profile permits protected operation-specific
finality to be enforced within a native transactional resource
controller without requiring external transmission of a separately
portable authorization token.
The controller maintains the proposed operation in a non-effective
condition, determines the actual pending operation, evaluates
protected authority predicates, commits internal validation state,
establishes bounded inline enablement, and verifies the actual
operation before effectuation.
Where the protected authorization state and native resource mutation
participate in the same atomic transaction, the system can prevent a
protected authorization from being consumed independently of the
corresponding committed resource effect.
The architecture also provides protected cache revalidation,
transaction-local denial evidence, and recovery procedures designed
to prevent stale authorization and unauthorized duplicate operation.
The claimed atomicity applies to the technical boundary actually
controlled by the selected resource system.
7.4.135. C-09.70 - Technical Summary
this implementation profile discloses a protected inline transaction-
finality architecture in which an artificial-intelligence-agent-
generated operation is submitted to an effectuation controller,
maintained in a Non-Effective State, reconstructed into a machine-
verifiable operation descriptor, evaluated against protected
authority conditions, and associated with an internally committed
validation-state representation.
A bounded execution-enabling condition is established within the
protected controller or transaction context without requiring
issuance of a separately portable authorization token.
Das Expires 25 April 2027 [Page 281]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The controller verifies the actual pending operation against the
protected validation state, current authority conditions, freshness,
effectuation scope, and controller identity.
Upon successful verification, the controller permits the governed
native resource effect and performs the required protected
authorization-state transition.
A native transactional implementation may atomically commit the
protected state transition and resource mutation.
Further embodiments provide protected cached authorization
revalidation and transactionlocal denial evidence.
The architecture may be implemented within database engines, storage
controllers, payment processors, cloud resource services, file-system
controllers, protected kernels, hardware transaction controllers, or
equivalent effectuation interfaces.
7.4.135.1. PROTECTED MULTI-AGENT INFLUENCE-LINEAGE GOVERNANCE WITH
AUTHORITY-SEPARATED INFORMATION FLOW, RETRIEVAL-TO-
7.4.135.2. EXECUTION CONTROL, DELEGATED OPERATION BINDING, AND
DOWNSTREAM FINALITY SINK VERIFICATION
7.5. Implementation Profile C-60
Source location: original disclosure pages 1044-1104. Source
technical content is presented here for implementation analysis;
numbering reflects the original profile family rather than a
requirement to implement every profile.
7.5.1. C-60.1 - Technical Field
this implementation profile relates to computer-implemented resource
security, database transaction processing, artificial-intelligence-
agent authorization, native resource-state protection, multiversion
concurrency control, transactional event processing, cross-object
integrity enforcement, and concurrency-safe resource modification.
Das Expires 25 April 2027 [Page 282]
Internet-Draft Kernel-Hardware Execution Finality October 2026
More particularly, the embodiment discloses a system in which a
resource engine receives a state-modifying operation initiated
directly or indirectly by an artificial-intelligence agent,
constructs an isolated prospective representation of the resource
state that would result from that operation and its applicable
transaction-associated dependencies, evaluates machineenforced
resource invariants over the combined prospective state, and commits
or rejects the resulting resource changes as part of a native
transaction.
The system further provides atomic association of accepted resource
modifications with transactional outbox records representing
authorized downstream asynchronous work.
The architecture may be implemented through:
(a) relational database engines; (b) transactional key-value stores;
(c) document databases with suitable transaction support;
(d) resource-management services;
(e) enterprise workflow databases;
(f) account and entitlement stores;
(g) cloud configuration databases;
(h) transactional storage engines;
(i) durable workflow state machines;
(j) distributed databases with appropriate consistency guarantees;
(k) transactional native resource controllers; or
(l) combinations thereof.
The invention does not depend upon a particular database vendor, SQL
dialect, programming language, cloud provider, transaction
implementation, or artificial-intelligence-agent framework.
The required isolation, atomicity, trigger semantics, and concurrency
guarantees must be supported by the actual selected resource engine.
7.5.2. PART I - TECHNICAL PROBLEM
Das Expires 25 April 2027 [Page 283]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.3. C-60.2 - Authorization Based Only on the Requested Operation
An artificial-intelligence agent may request a resource-state change
that appears permissible when evaluated independently.
For example, the agent may request:
UPDATE ACCOUNT A
or:
CHANGE SUPPLIER RESOURCE R
or:
CREATE ACCESS RECORD X.
A preliminary authorization mechanism may verify that the agent
possesses a role allowing the requested operation.
However, the actual resulting resource state may violate an invariant
after considering:
1. Existing resource relationships. 2. Other objects modified by
the same transaction. 3. Database triggers. 4. Stored procedures.
5. Automatically generated dependent records. 6. Resource ownership
restrictions. 7. Aggregate modification bounds. 8. Transaction-
associated event records. 9. Concurrent state changes. 10.
Application-specific prohibited transitions.
The identity or declared permission of the requesting agent does not,
by itself, establish that the resulting combined resource state is
authorized.
7.5.4. C-60.3 - Cross-Object Invariant Problem
A resource operation may modify several related objects.
For example, transferring ownership of an enterprise resource may
involve:
(a) modification of the resource's owner field; (b) modification of
the previous owner's resource index; (c) modification of the new
owner's resource index; (d) changes to access-control relationships;
and (e) creation of an audit or notification event.
Authorizing only the primary object's proposed modification may
permit an inconsistent combined state.
Das Expires 25 April 2027 [Page 284]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The invention evaluates the relevant post-operation relationships
before committing the transaction.
7.5.5. C-60.4 - Trigger-Generated Effect Problem
A database mutation may activate a trigger or stored procedure.
The trigger may:
1. Modify another table. 2. Update an aggregate counter. 3.
Generate a dependent record. 4. Record an audit entry.
5. Add a transactional outbox event. 6. Invoke another transaction-
associated rule.
A validation performed solely on the initial request may omit such
changes.
The system therefore identifies transaction-associated dependencies
and evaluates the combined projected state.
7.5.6. C-60.5 - Concurrent Authorization Problem
Two AI-agent operations may each appear valid against the same
initial state.
Their combined committed effects may nevertheless violate a shared
invariant.
For example:
Current number of privileged administrators = 1.
Operation A removes Administrator X.
Operation B removes Administrator Y.
Each transaction may independently observe the other administrator
and conclude that at least one administrator remains.
If both transactions commit without adequate concurrency control, no
privileged administrator remains.
This is a representative write-skew problem.
The system must prevent acceptance of a combined state violating the
applicable invariant.
Das Expires 25 April 2027 [Page 285]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.7. C-60.6 - Transactional Outbox Problem
An authorized resource mutation may require a downstream asynchronous
operation.
For example:
RESOURCE UPDATE
→ OUTBOX EVENT
→ WORKER
→ EXTERNAL NOTIFICATION.
If the primary resource change commits but the outbox record is not
written, the required downstream processing may be omitted.
If the outbox record commits but the primary resource change is
rejected, a worker may act upon a resource state that never became
valid.
The embodiment atomically associates accepted primary resource
modifications with required transactional outbox records.
7.5.8. C-60.7 - Distinction From Upstream API Admission
An upstream API gateway may determine whether a request is permitted
based on its predicted effects.
However, the actual native resource state may change between
admission and commit.
The native resource engine has access to transaction-specific state
and concurrency mechanisms.
This embodiment therefore performs the required authorization during
the native resource transaction.
An upstream effect-closure admission system may optionally be used in
addition, but it does not replace the claimed transaction-native
invariant evaluation.
Das Expires 25 April 2027 [Page 286]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.9. PART II - CENTRAL TECHNICAL PRINCIPLE
7.5.10. C-60.8 - Authorization of the Resulting State
The central principle is:
A state-modifying operation is authorized only when the combined
projected resource state resulting from the operation and its
applicable transaction-associated dependencies satisfies the required
machine-enforced invariants at the commit boundary.
The system does not rely exclusively upon the requested API method,
identity role, or original input parameters.
It evaluates the state that would result if the transaction were
committed.
7.5.11. C-60.9 - Representative Authorization Predicate
For a transaction T:
COMMIT_ALLOWED(T) =
VALID_REQUEST_CONTEXT
AND VALID_NATIVE_RESOURCE_AUTHORITY
AND VALID_PROJECTED_STATE(T)
AND REQUIRED_DEPENDENCIES_INCLUDED(T)
AND ALL_REQUIRED_INVARIANTS_SATISFIED(T)
AND VALID_TRANSACTIONAL_OUTBOX_STATE(T)
AND CONCURRENCY_STATE_ACCEPTABLE(T).
The exact invariant set and authorization predicates are selected
according to the resource engine and enforcement point
implementation.
7.5.12. C-60.10 - Atomicity Boundary
The native transaction controls:
Das Expires 25 April 2027 [Page 287]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Primary resource modifications. 2. Dependent modifications
included in the same native transaction. 3. Relevant invariant
checks. 4. Required transactional outbox entries. 5. Commit or
rollback. 6. Appropriate concurrency validation.
A successful transaction commits its supported resource changes and
outbox records together.
An unsuccessful transaction commits neither the prohibited resource
changes nor their associated outbox records.
External downstream effects are not automatically included in the
resource engine's native atomicity boundary.
7.5.13. C-60.11 - No Separate DAS Receipt Requirement
The resource engine may make its authorization decision using its
native transaction state and invariant evaluator.
It need not issue:
(a) an independent protected validation receipt;
(b) a separately transferable finality capability; or
(c) a downstream sink-bound enablement artifact.
Those mechanisms may be combined with the native transaction engine
in another implementation.
However, this implementation profile is independently implementable
through transaction-native authorization, state projection,
isolation, and commit control.
7.5.14. PART III - PRINCIPAL SYSTEM COMPONENTS
7.5.15. C-60.12 - Agent-Associated Resource Request Interface
A Resource Request Interface receives state-modifying operations
initiated directly or indirectly by an AI agent.
The request may originate through:
(a) a controlled API; (b) an application service; (c) a database
driver; (d) a resource-management service; (e) a workflow controller;
(f) a delegated worker; (g) an enterprise connector; or (h) a native
resource operation interface.
Das Expires 25 April 2027 [Page 288]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The interface associates the operation with the applicable agent,
task, resource, and authority context.
7.5.16. C-60.13 - Native Resource Engine
A Native Resource Engine controls the authoritative resource state
and its transactional modification.
It provides the supported facilities necessary to:
1. Begin a transaction.
2. Read a suitable resource snapshot. 3. Stage prospective changes.
4. Execute transaction-associated dependencies. 5. Evaluate
invariants. 6. Detect relevant concurrent conflicts. 7. Commit or
roll back. 8. Persist corresponding outbox records.
7.5.17. C-60.14 - Transaction-State Mechanism
The Transaction-State Mechanism establishes an isolated prospective
representation of the relevant resource objects.
The representation may use:
(a) multiversion concurrency control; (b) transaction-local write
sets; (c) copy-on-write state; (d) versioned resource objects; (e)
private transactional buffers; (f) isolated state-machine proposals;
or (g) equivalent transaction-state facilities.
The prospective state is not externally committed while validation
remains incomplete.
7.5.18. C-60.15 - Dependency Evaluator
A Dependency Evaluator identifies additional resource-state
transitions or event records generated by:
1. 2. 3. 4. 5. 6.
Database triggers. Stored procedures. Resource rules. Transaction-
associated event handlers. Resource update cascades. Transactional
workflow rules.
It identifies the dependencies relevant to the proposed operation and
the selected invariant set.
Das Expires 25 April 2027 [Page 289]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.19. C-60.16 - Projected-State Generator
A Projected-State Generator determines the combined prospective
resource state.
It applies:
(a) the initiating modification; (b) applicable dependent
modifications; (c) transaction-associated trigger effects; and (d)
relevant outbox record generation.
The resulting representation is evaluated before native commit.
7.5.20. C-60.17 - Invariant Evaluator
An Invariant Evaluator checks machine-enforced constraints over the
combined projected state.
Representative invariant classes include:
OBJECT_INTEGRITY
FIELD_CONSISTENCY
OWNERSHIP_RESTRICTION
AUTHORIZATION_CONSTRAINT
AGGREGATE_MUTATION_BOUND
CROSS_OBJECT_RELATIONSHIP
PROHIBITED_STATE_TRANSITION
RESOURCE_VERSION_CONSISTENCY
OUTBOX_ASSOCIATION.
7.5.21. C-60.18 - Native Transaction Controller
The Native Transaction Controller determines whether to commit,
reject, or re-evaluate the transaction.
It performs the commit under the applicable native isolation and
concurrency guarantees.
Das Expires 25 April 2027 [Page 290]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.22. C-60.19 - Transactional Outbox Controller
The Transactional Outbox Controller constructs and persists event
records required for downstream processing.
The outbox records are associated with the accepted primary state
modification within the same native transaction.
7.5.23. C-60.20 - Outbox Dispatch Worker
An Outbox Dispatch Worker reads committed event records and performs
corresponding downstream operations.
It verifies applicable event identity, resource version, and
permitted downstream effect classification.
The worker maintains a durable processing state to manage duplicate
delivery, retries, and inconsistent events.
7.5.24. C-60.21 - Concurrent Conflict Controller
A Concurrent Conflict Controller detects conditions in which a
transaction's projected state is no longer valid because of another
concurrent modification.
It may use:
(a) serializable isolation; (b) explicit predicate or resource locks;
(c) optimistic concurrency validation;
(d) compare-and-swap version checks;
(e) transaction retries;
(f) serialization fences; or
(g) another mechanism sufficient for the selected invariants.
7.5.25. PART IV - RESOURCE-STATE REPRESENTATION
7.5.26. C-60.22 - Resource Object
A Resource Object means a stateful object governed by the native
resource engine.
Examples include:
Das Expires 25 April 2027 [Page 291]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Database records. 2. Account objects. 3. Access-control
records. 4. Ownership records. 5. Cloud resource configurations. 6.
Inventory entries. 7. Workflow state. 8. Storage metadata. 9.
Transaction records. 10. Related resource indexes.
7.5.27. C-60.23 - Resource State Record
A representative record comprises:
ResourceID = RESOURCE-6001
ResourceClass = ENTERPRISE_RECORD
ResourceVersion = 41
OwnerID = PRINCIPAL-A
ResourceStatus = ACTIVE
AuthorizationScope = TASK-204
StateDigest = DIGEST-6001.
The values are illustrative.
The version identifies a relevant committed state of the resource.
7.5.28. C-60.24 - Resource Version
A Resource Version identifies the committed state against which a
transaction may evaluate or modify an object.
A version may comprise:
(a) an integer generation; (b) a transaction identifier; (c) an MVCC
tuple version; (d) a database commit sequence; (e) an authenticated
state reference; or (f) another native consistency identifier.
The required version semantics are defined by the selected engine.
7.5.29. C-60.25 - Prospective State
A Prospective State is the state that would exist if the proposed
transaction and all applicable transaction-local dependencies were
committed.
For example:
Das Expires 25 April 2027 [Page 292]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Committed State:
ResourceOwner = PRINCIPAL-A.
Proposed Operation:
TransferOwnership(PRINCIPAL-B).
Prospective State:
ResourceOwner = PRINCIPAL-B.
The prospective state is initially isolated from ordinary committed-
state readers according to the transaction engine's isolation
semantics.
7.5.30. C-60.26 - Transaction Read Set
A Transaction Read Set identifies resource objects and predicates
relied upon during authorization.
A representative set may contain:
ReadObjectIDs.
ReadResourceVersions.
ReadPredicateReferences.
ObservedAggregateValues.
AuthorityStateReferences.
The read set supports appropriate concurrency validation.
7.5.31. C-60.27 - Transaction Write Set
A Transaction Write Set identifies proposed modifications to resource
objects.
A representative write entry comprises:
ResourceID.
ExpectedVersion.
ProposedNewState.
Das Expires 25 April 2027 [Page 293]
Internet-Draft Kernel-Hardware Execution Finality October 2026
ModificationClass.
OriginatingOperationID.
The write set remains uncommitted until required invariant evaluation
and commit authorization succeed.
7.5.32. C-60.28 - Dependent Change Set
A Dependent Change Set contains additional resource-state
modifications generated by transaction-associated rules.
For example:
PrimaryChange:
UPDATE ACCOUNT OWNER.
DependentChanges:
UPDATE OWNER INDEX.
UPDATE ACCESS RELATIONSHIP.
CREATE AUDIT RECORD.
CREATE OUTBOX EVENT.
The combined state is evaluated for consistency.
7.5.33. PART V - DEPENDENCY EVALUATION
7.5.34. C-60.29 - Applicable Resource Dependencies
The Dependency Evaluator identifies dependencies that may be
triggered by the proposed state modification.
Examples include:
(a) a BEFORE UPDATE trigger; (b) an AFTER UPDATE trigger executing
within the same transaction;
(c) a stored procedure invoked by the operation;
(d) a cascading foreign-key action;
(e) a resource ownership update rule;
Das Expires 25 April 2027 [Page 294]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(f) a transactional event-record generator;
(g) an application rule executed inside the same transaction.
The engine determines the selected resource state's actual dependency
semantics.
7.5.35. C-60.30 - Trigger Ordering
Some triggers execute before the primary modification.
Others execute after a row or statement modification but before
transaction commit.
The implementation must preserve the native engine's defined trigger
ordering.
The final invariant check evaluates the combined state that is
actually eligible for commit.
It must not assume that all trigger effects can be predicted
accurately by a detached simulation that does not execute the
applicable native rules.
7.5.36. C-60.31 - Trigger Closure
An applicable trigger may create additional changes that activate
further transactionassociated triggers.
The Dependency Evaluator may compute:
PrimaryOperation
→ Trigger A
→ Dependent Change B
→ Trigger C
→ Dependent Change D.
The evaluator continues until the required transaction-associated
dependency state is resolved, or the engine rejects an unsupported or
unbounded dependency condition.
Das Expires 25 April 2027 [Page 295]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.37. C-60.32 - Trigger Cycle Handling
A trigger cycle may produce repeated modifications.
A selected implementation may use:
1. Native trigger recursion limits. 2. Cycle detection. 3.
Statement execution bounds. 4. Recursive dependency-state tracking.
5. Resource mutation limits. 6. Transaction timeouts.
An unresolved cycle does not justify committing a partially evaluated
resource state.
Where the required invariant cannot be evaluated, the transaction is
rejected or otherwise kept noncommitted.
7.5.38. C-60.33 - External Operations Inside Triggers
A database trigger may attempt external network communication or
invoke a nontransactional service.
Such external effects may not be rolled back when the native
transaction fails.
Therefore, the principal atomic outbox implementation prohibits or
isolates external irreversible effects during speculative resource-
state evaluation.
Instead, the transaction writes a durable outbox record describing
the permitted downstream operation.
The external operation is dispatched only after commit.
Where the selected resource engine permits external side effects
inside triggers, the implementation must separately address their
nontransactional semantics and cannot assume native rollback reverses
them.
7.5.39. PART VI - PROJECTED STATE GENERATION
7.5.40. C-60.34 - Combined State Construction
The Projected-State Generator constructs a combined state
representation:
ProjectedState(T) = Apply( BaseState, PrimaryMutation,
ApplicableDependentMutations ).
Das Expires 25 April 2027 [Page 296]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The projected state also includes transaction-associated outbox
records where relevant to the invariant evaluation.
7.5.41. C-60.35 - Prospective State Isolation
Other transactions do not observe uncommitted prospective
modifications as though they were authoritative committed state.
The mechanism may use native snapshot isolation, serializable
transactions, or equivalent isolation.
However, snapshot isolation alone does not universally prevent write-
skew anomalies.
The selected implementation must use additional predicate locking,
serializable validation, or equivalent mechanisms where shared
invariants require them.
7.5.42. C-60.36 - Projected-State Completeness
Before invariant evaluation, the controller establishes whether the
relevant transactionassociated effects have been included.
If a mandatory trigger or resource rule cannot be resolved, the
system does not certify the projected state as complete.
The controller may reject the transaction or invoke a supported
conservative procedure.
7.5.43. C-60.37 - Resource-Scoped Projection
A full copy of the entire database is not required.
The transaction may project only:
1. Objects directly modified. 2. Dependent objects. 3. Aggregate
records. 4. Resource-version predicates. 5. Objects necessary to
evaluate the applicable invariants. 6. Required transactional event
entries.
The projection is sufficient when those objects and predicates cover
the invariant's relevant read and write dependencies.
7.5.44. PART VII - RESOURCE INVARIANTS
Das Expires 25 April 2027 [Page 297]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.45. C-60.38 - Object Integrity Invariant
An Object Integrity Invariant requires a resource object to satisfy
defined integrity conditions.
For example:
ResourceID must remain unique.
Required fields must be present.
Object version must be valid.
The native transaction controller rejects a projected state violating
the invariant.
7.5.46. C-60.39 - Field Consistency Invariant
A Field Consistency Invariant governs relationships among fields.
For example:
If ResourceStatus = CLOSED,
then ActiveCredentialCount = 0.
A transaction attempting to close a resource while leaving an active
credential reference may be rejected.
7.5.47. C-60.40 - Ownership Invariant
An Ownership Invariant governs permitted owner relationships.
For example:
A protected resource must have exactly one current owner.
A transfer operation must update the resource and corresponding
ownership records consistently.
The projected state is checked before commit.
7.5.48. C-60.41 - Authorization Constraint
An Authorization Constraint governs whether a particular agent-
associated operation may produce the proposed resource-state
transition.
Das Expires 25 April 2027 [Page 298]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A representative constraint may require:
(a) valid originating identity; (b) permission to modify the target
resource; (c) current task scope; (d) permitted state transition; (e)
valid resource ownership; or (f) another machine-enforced condition.
The authorization is evaluated in relation to the proposed resulting
state.
7.5.49. C-60.42 - Aggregate Mutation Bound
A transaction may be subject to a maximum number or aggregate amount
of permitted modifications.
For example:
AggregateActiveAdministrators ≤ 5.
A transaction adding an administrator may require evaluation of the
resulting aggregate.
Concurrent transactions must not each rely upon the same stale
aggregate value to exceed the bound.
7.5.50. C-60.43 - Prohibited State-Transition Relationship
An invariant may prohibit selected transitions.
For example:
ResourceStatus = LOCKED
must not transition directly to:
ResourceStatus = EXTERNALLY_PUBLISHED
without an authorized intermediate state.
The native transaction controller evaluates the actual proposed
transition.
7.5.51. C-60.44 - Inter-Object Relationship Invariant
A dependent enforcement point implementation may require:
If Resource A references Resource B,
then Resource B must exist and satisfy a defined compatible state.
Das Expires 25 April 2027 [Page 299]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The projected combined state is checked for consistency across the
related objects.
7.5.52. PART VIII - CROSS-OBJECT MODIFICATION
7.5.53. C-60.45 - Multiple Resource Objects
A state-modifying operation may affect:
PrimaryObject.
DependentObjectA.
DependentObjectB.
AggregateObject.
AuditObject.
OutboxRecord.
The transaction controller evaluates the relevant combined state.
7.5.54. C-60.46 - Cross-Object Atomicity
In one implementation, all affected objects reside within a native
transaction domain supporting atomic commit.
If any required invariant fails, none of the transaction's covered
object modifications become committed.
Where objects reside in separate resource engines lacking a shared
atomic transaction, the implementation must use a suitable
distributed transaction or narrow its enforcement point of atomicity
to the actual native transaction domain.
7.5.55. C-60.47 - Example Cross-Object Ownership Change
Before the operation:
Resource R owner = A.
OwnerIndex A includes R.
OwnerIndex B excludes R.
Proposed operation:
Das Expires 25 April 2027 [Page 300]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Transfer R from A to B.
Required projected state:
Resource R owner = B.
OwnerIndex A excludes R.
OwnerIndex B includes R.
The invariant evaluator checks these relationships before commit.
If one dependent update fails, the transaction is rejected rather
than committing a partially inconsistent ownership transfer.
7.5.56. C-60.48 - Shared Aggregate Object
Several transactions may depend upon a shared aggregate object.
For example:
ActiveAccountCount.
ResourceQuotaUsed.
PrivilegedRoleCount.
The aggregate object may be updated or locked as part of the
transaction to prevent concurrent invariant violations.
An implementation may alternatively use serializable predicate
validation rather than a physical aggregate counter.
7.5.57. PART IX - TRANSACTIONAL OUTBOX
7.5.58. C-60.49 - Transactional Outbox Record
A Transactional Outbox Record represents an authorized downstream
asynchronous operation.
A representative record comprises:
OutboxEventID = EVENT-6001
LogicalOperationID = OP-6001
ResourceID = RESOURCE-6001
Das Expires 25 April 2027 [Page 301]
Internet-Draft Kernel-Hardware Execution Finality October 2026
CommittedResourceVersion = 42
PermittedEffectClass = CUSTOMER_NOTIFICATION
PayloadReference = PAYLOAD-6001
EventStatus = PENDING
EventGeneration = 17.
The values are illustrative.
7.5.59. C-60.50 - Outbox Creation
The native transaction controller creates the required outbox entries
as part of the same transaction that modifies the primary resource.
The outbox event may identify:
1. The logical operation. 2. The affected resource. 3. The
resulting resource version. 4. The permitted downstream effect
class. 5. The authorized destination or resource scope. 6. The
event identity. 7. The event payload or digest.
7.5.60. C-60.51 - Atomic Commit Relationship
A representative transaction includes:
UPDATE RESOURCE
x
UPDATE DEPENDENT OBJECT
x
INSERT OUTBOX EVENT.
The native engine commits all required transaction-covered records or
none.
The outbox worker cannot obtain a committed event for a resource
mutation that the same transaction rejected, assuming it reads only
committed outbox entries and the underlying database supplies the
required atomicity.
Das Expires 25 April 2027 [Page 302]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.61. C-60.52 - Rejection Behavior
If the invariant evaluator rejects the transaction:
1. The primary resource modification is not committed. 2. The
dependent resource modifications are not committed. 3. The
associated transactional outbox entries are not committed. 4. The
transaction's reserved native state is released or rolled back
according to engine semantics. 5. The initiating operation receives
a rejection or retry decision.
7.5.62. C-60.53 - Post-Commit Dispatch
The outbox dispatcher reads committed event records.
It verifies applicable event constraints.
It may then invoke the downstream operation.
The dispatch is not part of the original database transaction unless
a supported distributed atomic mechanism explicitly includes it.
7.5.63. C-60.54 - At-Least-Once Delivery
An outbox dispatcher may deliver an event more than once because of
retries or acknowledgment loss.
The architecture therefore supports idempotency or duplicate-event
rejection by the downstream worker.
Exactly-once external effectuation is not assumed merely because the
outbox entry itself was committed once.
7.5.64. C-60.55 - Event Identity Constraint
A downstream event worker may maintain a durable record of processed
event identities.
A representative uniqueness key is:
(ConsumerID, OutboxEventID).
If the same event is delivered again to the same consumer, the worker
can reject duplicate processing or return the previous result.
The mechanism must be durable and coordinated with the downstream
effect to guarantee prevention of duplicate resource changes.
Das Expires 25 April 2027 [Page 303]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.65. C-60.56 - Resource-Version Binding
The outbox event references the resource version associated with the
committed transaction.
| The worker verifies that the event was generated from a valid committed resource state. The worker must distinguish a stale but legitimate historical event from an inconsistent or forged event. A newer current resource version alone does not automatically make an older event invalid. The appropriate decision depends upon the effect class and ordering policy. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-60.57 - Version-Sensitive Downstream Effects For an operation requiring only the latest resource version, the worker may reject an event superseded by a newer version. For an operation representing a historical audit event, the worker may process an older version even after further resource changes. The version-consistency policy is defined by the downstream effect contract. |
| C-60.58 - Permitted Effect Class An outbox event identifies the downstream effect class authorized by the native transaction. For example: SEND_NOTIFICATION. UPDATE_SEARCH_INDEX. SYNCHRONIZE_APPROVED_RESOURCE. The worker verifies that the event's operation falls within that class. A malicious or corrupted event cannot automatically substitute a privileged resource modification for an authorized notification. |
7.5.66. PART X - CONCURRENCY AND CONFLICT CONTROL
7.5.67. C-60.59 - Concurrent Operations
Two or more AI-agent operations may execute concurrently against
related resource objects.
The resource engine must ensure that their committed results satisfy
the applicable invariants.
| C-60.60 - Optimistic Concurrency An optimistic implementation records the resource versions read during state projection. Before commit, the controller verifies that relevant versions or predicates remain valid. A conflict causes the operation to be retried, re-evaluated, or rejected. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-60.61 - Pessimistic Concurrency A pessimistic implementation obtains locks covering the required resource objects or invariant predicates. The locks prevent conflicting modifications from invalidating the projected state before commit. The lock scope must correspond to the invariant being protected. |
| C-60.62 - Serializable Isolation A serializable transaction implementation may enforce an execution equivalent to some serial ordering of the committed transactions. This can prevent relevant write-skew anomalies. The implementation must use the actual serializable semantics supplied by the resource engine, including appropriate handling of serialization failures. |
7.5.68. C-60.63 - Snapshot Isolation Limitation
Snapshot isolation may permit two transactions to read the same state
and update disjoint objects.
Each transaction's local projected state may satisfy the invariant.
The combined committed state may violate it.
Accordingly, snapshot isolation alone is not universally sufficient
for enforcement point(s) 63.
The implementation may add explicit invariant locks, predicate
conflict detection, aggregateobject updates, or another suitable
mechanism.
7.5.69. C-60.64 - Optimistic Revalidation
When a relevant concurrent change occurs, the transaction controller
may:
Das Expires 25 April 2027 [Page 304]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Abort the current transaction. 2. Obtain a new resource
snapshot. 3. Reconstruct the projected state. 4. Re-execute
applicable transaction-associated dependencies. 5. Reevaluate the
invariants. 6. Attempt commit under the required concurrency checks.
The previously approved projection is not reused without accounting
for the changed state.
7.5.70. C-60.65 - Retry Bound
A resource transaction may repeatedly encounter conflicts.
The implementation may impose:
MaximumRetryCount.
MaximumRetryDuration.
MaximumTransactionAge.
A transaction exhausting the bound is rejected or returned for later
authorized retry.
The system does not waive invariant checks to force progress.
7.5.71. PART XI - RESOURCE-NATIVE AUTHORIZATION
7.5.72. C-60.66 - Agent Context Binding
The resource engine may associate the transaction with:
AgentContextID.
TaskID.
OriginatingServiceID.
RequestedOperationID.
ApplicableResourceAuthority.
TransactionID.
The engine verifies the relevant identity and resource scope
according to its native authorization mechanism.
Das Expires 25 April 2027 [Page 305]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.73. C-60.67 - Operation Authorization
An agent may possess general authority to request a class of resource
modifications.
However, the final transaction may still fail when its projected
combined state violates a resource invariant.
Thus:
PERMISSION TO REQUEST
is distinct from:
AUTHORIZATION TO COMMIT THE RESULTING STATE.
7.5.74. C-60.68 - Trigger Authority
A trigger may execute using privileges different from those of the
initiating caller.
The resource engine must define the effect and authorization
semantics of that trigger.
A trigger running with elevated native privileges does not
automatically make a prohibited projected state acceptable.
The invariant evaluator checks the resulting resource state
regardless of which transactionassociated component produced the
change.
7.5.75. C-60.69 - Resource Ownership Check
Where authorization depends upon resource ownership, the transaction
may read the current owner and proposed owner.
The invariant evaluator checks the transition under the same
concurrency protection used for the commit.
An ownership check performed against an earlier stale state is
insufficient when a concurrent change invalidates it.
7.5.76. PART XII - COMPLETE PRINCIPAL WORKFLOW
7.5.77. C-60.70 - Thirty-Four-Step Transaction Workflow
Das Expires 25 April 2027 [Page 306]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.78. Step C60-01 - Resource operation receipt
The native resource engine receives an AI-agent-associated state-
modifying request.
7.5.79. Step C60-02 - Requesting context identification
The originating agent, task, and applicable authority are identified.
7.5.80. Step C60-03 - Transaction initiation
The engine begins an isolated native transaction.
7.5.81. Step C60-04 - Resource snapshot acquisition
The required current resource state is obtained.
7.5.82. Step C60-05 - Read-set recording
The resource objects and invariant predicates relied upon are
identified.
7.5.83. Step C60-06 - Primary change construction
The requested modification is staged.
7.5.84. Step C60-07 - Dependency discovery
Applicable triggers, stored procedures, resource rules, and event
handlers are identified.
7.5.85. Step C60-08 - Dependent transition evaluation
Transaction-associated dependent changes are calculated or executed
within the transaction.
7.5.86. Step C60-09 - Cross-object expansion
Additional related resource objects are incorporated as required.
7.5.87. Step C60-10 - Trigger-chain evaluation
Applicable nested transaction-associated effects are processed.
7.5.88. Step C60-11 - Dependency-completeness determination
The controller verifies that relevant dependency processing is
complete.
Das Expires 25 April 2027 [Page 307]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.89. Step C60-12 - Prospective state generation
The combined projected resource state is constructed.
7.5.90. Step C60-13 - Applicable invariant selection
Object, field, ownership, authorization, aggregate, and transition
invariants are identified.
7.5.91. Step C60-14 - Object integrity evaluation
Object-level constraints are checked.
7.5.92. Step C60-15 - Field consistency evaluation
Required field relationships are checked.
7.5.93. Step C60-16 - Cross-object invariant evaluation
Relevant inter-object relationships are checked.
7.5.94. Step C60-17 - Aggregate invariant evaluation
Shared quotas and aggregate restrictions are evaluated.
7.5.95. Step C60-18 - Authorization-state evaluation
The requested transition is checked against current native authority.
7.5.96. Step C60-19 - Invariant decision
The transaction is classified as eligible or ineligible for commit.
7.5.97. Step C60-20 - Outbox effect classification
Required asynchronous downstream effects are identified.
7.5.98. Step C60-21 - Event identity allocation
Unique event identities are established.
7.5.99. Step C60-22 - Resource-version association
The proposed committed resource version is associated with each
required outbox event.
Das Expires 25 April 2027 [Page 308]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.100. Step C60-23 - Transactional outbox insertion
The required event records are staged within the native transaction.
7.5.101. Step C60-24 - Final projected-state verification
The complete proposed transaction state is checked.
7.5.102. Step C60-25 - Concurrency validation
Relevant resource versions, locks, or predicates are verified.
7.5.103. Step C60-26 - Conflict handling
An invalidated projection is retried or rejected.
7.5.104. Step C60-27 - Native commit decision
The engine determines whether the transaction satisfies all required
conditions.
7.5.105. Step C60-28 - Atomic commit or rollback
The native engine commits the primary changes and outbox records
together, or rejects both.
7.5.106. Step C60-29 - Commit outcome registration
The committed resource version and transaction outcome are recorded.
7.5.107. Step C60-30 - Outbox visibility
Committed outbox events become eligible for asynchronous processing.
7.5.108. Step C60-31 - Downstream event verification
The worker verifies event identity, resource version, and permitted
effect class.
7.5.109. Step C60-32 - Duplicate-event handling
Repeated event delivery is detected and controlled.
7.5.110. Step C60-33 - Downstream processing
An eligible event is processed according to native worker semantics.
Das Expires 25 April 2027 [Page 309]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.111. Step C60-34 - Completion and reconciliation
The downstream processing state is recorded and recoverable failures
are handled.
7.5.112. PART XIII - REFERENCE IMPLEMENTATION ALGORITHMS
C-60.71 - Algorithm A: Native Transaction Initialization
function BeginAgentResourceTransaction(request):
context = AuthenticateOriginatingResourceContext(
request.agent_context )
if context is invalid:
return DENIED
operation = CanonicalizeResourceMutation(request)
if operation is invalid:
return DENIED transaction = NativeResourceEngine.beginTransaction({
isolation: REQUIRED_ISOLATION_LEVEL, agent_context: context,
logical_operation_id: operation.id })
if transaction failed:
return DENIED
return transaction
The required isolation level depends upon the selected invariant set.
C-60.72 - Algorithm B: Prospective State Construction
function ConstructProjectedResourceState(
transaction, proposed_operation ):
base_state = transaction.readRequiredResourceState(
proposed_operation )
primary_change = ApplyMutationToTransactionLocalState(
Das Expires 25 April 2027 [Page 310]
Internet-Draft Kernel-Hardware Execution Finality October 2026
transaction, proposed_operation )
dependencies = ResolveApplicableResourceDependencies(
proposed_operation, transaction )
for each dependency in NativeDependencyExecutionOrder(
dependencies ):
if not ExecuteDependencyWithinTransaction(
transaction, dependency ):
transaction.rollback() return DENIED if not
VerifyDependencyClosureComplete(transaction):
transaction.rollback() return DENIED projected_state =
MaterializeRelevantProspectiveState(
transaction )
return projected_state
The primary and dependent changes remain uncommitted.
C-60.73 - Algorithm C: Cross-Object Invariant Evaluation
function EvaluateCrossObjectInvariants(
transaction, projected_state, invariant_set ):
for each invariant in invariant_set:
relevant_objects = ResolveInvariantReadDomain(
transaction, invariant, projected_state )
if not VerifyRequiredConcurrencyProtection(
transaction, relevant_objects, invariant ):
return REVALIDATION_REQUIRED
result = EvaluateInvariantOverProjectedState(
invariant, projected_state, relevant_objects )
Das Expires 25 April 2027 [Page 311]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if result != SATISFIED:
return INVARIANT_FAILURE
return ALL_INVARIANTS_SATISFIED
The required read domain may include predicate-defined objects, not
only explicitly modified rows.
C-60.74 - Algorithm D: Combined Native Authorization
function AuthorizeNativeProjectedState(
transaction, proposed_operation ):
projected = ConstructProjectedResourceState(
transaction, proposed_operation )
if projected is invalid:
return DENIED authority = ResolveCurrentNativeResourceAuthority(
transaction.agent_context )
if not VerifyRequestedTransitionAuthority(
authority, proposed_operation, projected ):
transaction.rollback() return DENIED invariants =
ResolveApplicableResourceInvariants(
proposed_operation, projected )
result = EvaluateCrossObjectInvariants(
transaction, projected, invariants )
if result != ALL_INVARIANTS_SATISFIED:
transaction.rollback() return DENIED_OR_RETRY return
ELIGIBLE_FOR_OUTBOX_AND_COMMIT
The authorization decision is based on the projected combined state.
C-60.75 - Algorithm E: Atomic Outbox Creation and Commit
function CommitResourceMutationWithOutbox(
Das Expires 25 April 2027 [Page 312]
Internet-Draft Kernel-Hardware Execution Finality October 2026
transaction, authorized_projection ):
if not VerifyCurrentTransactionAuthorization(
transaction, authorized_projection ):
transaction.rollback() return DENIED events =
DeriveRequiredTransactionalOutboxEvents(
authorized_projection )
for each event in events:
if not VerifyPermittedDownstreamEffectClass(event):
transaction.rollback() return DENIED event_id =
AllocateStableOutboxEventID(
transaction.logical_operation_id, event )
version_reference = ResolveProposedCommittedVersion(
transaction, event.resource_id )
transaction.insertOutbox({
event_id: event_id, logical_operation_id:
transaction.logical_operation_id, resource_id: event.resource_id,
committed_version_reference: version_reference,
permitted_effect_class: event.effect_class, payload: event.payload,
status: PENDING })
if not RevalidateCommitCriticalPredicates(
transaction ):
transaction.rollback() return RETRY_REQUIRED
result = transaction.commit()
if result == COMMITTED:
return COMMITTED_WITH_OUTBOX return REJECTED_OR_INDETERMINATE
The transaction engine must support atomic resource and outbox
persistence.
C-60.76 - Algorithm F: Optimistic Conflict Detection
Das Expires 25 April 2027 [Page 313]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function ValidateProspectiveStateVersions(
transaction, projection ):
for each read_dependency in projection.read_set:
current = NativeResourceEngine.getCommitRelevantVersion(
read_dependency )
if not VersionPredicateStillValid(
read_dependency, current ):
return CONFLICT
for each aggregate_predicate in projection.invariant_predicates:
if not VerifySerializablePredicateProtection(
transaction,
aggregate_predicate ):
return CONFLICT
return VALID
Simple version comparison of individual rows may not detect phantom
or predicate conflicts.
The selected engine must supply the required additional predicate
protection.
C-60.77 - Algorithm G: Conflict-Safe Transaction Retry
function ExecuteWithConflictReevaluation(
agent_operation ):
for attempt in 1..MAX_TRANSACTION_RETRIES:
transaction = BeginAgentResourceTransaction(
agent_operation )
if transaction is invalid:
Das Expires 25 April 2027 [Page 314]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED
projection = ConstructProjectedResourceState(
transaction, agent_operation )
if projection is invalid:
transaction.rollback() return DENIED
if not EvaluateRequiredInvariants(
transaction, projection ):
transaction.rollback() return DENIED
if not ValidateProspectiveStateVersions(
transaction, projection ):
transaction.rollback() continue
PrepareRequiredTransactionalOutbox(
transaction, projection )
result = transaction.commit()
if result == COMMITTED:
return COMMITTED if result == SERIALIZATION_CONFLICT:
continue
return REJECTED_OR_RECONCILIATION_REQUIRED return
CONFLICT_RETRY_LIMIT_REACHED
The retry reconstructs the projected state rather than reusing an
invalid earlier approval.
C-60.78 - Algorithm H: Native Shared-Invariant Lock
function AcquireSharedInvariantProtection(
transaction, invariant_id, resource_scope ):
lock_key = CanonicalInvariantLockKey({
Das Expires 25 April 2027 [Page 315]
Internet-Draft Kernel-Hardware Execution Finality October 2026
invariant_id: invariant_id, scope: resource_scope })
if not transaction.acquireLock(lock_key):
return CONFLICT
return LOCK_HELD_UNTIL_TRANSACTION_COMPLETION
A deployment may employ a native lockable aggregate row or advisory
lock with appropriate semantics.
The lock must actually serialize transactions capable of violating
the same shared invariant.
C-60.79 - Algorithm I: Downstream Outbox Event Verification
function VerifyCommittedOutboxEvent(event, consumer):
if not VerifyCommittedEventIdentity(event):
return DENIED
if not VerifyPermittedEffectClass(
event.effect_class, consumer ):
return DENIED if not VerifyCommittedResourceVersionReference(
event.resource_id, event.committed_version_reference ):
return DENIED
if not VerifyEventOrderingPolicy(event, consumer):
return DENIED_OR_DEFERRED if AlreadyProcessedByConsumer(
consumer.id, event.event_id ):
return DUPLICATE
return ELIGIBLE_FOR_IDEMPOTENT_PROCESSING
A later current resource version is not automatically grounds for
rejecting a historically valid event.
C-60.80 - Algorithm J: Durable Duplicate-Event Processing
function ProcessOutboxEventExactlyOnceLocally(
Das Expires 25 April 2027 [Page 316]
Internet-Draft Kernel-Hardware Execution Finality October 2026
consumer, event ):
begin consumer_native_transaction
if ConsumerEventLedger.exists(
consumer.id, event.event_id ):
rollback return ALREADY_PROCESSED
if not VerifyCommittedOutboxEvent(event, consumer):
rollback return DENIED
ApplyPermittedLocalResourceEffect(
consumer, event )
ConsumerEventLedger.insertUnique({
consumer_id: consumer.id, event_id: event.event_id, status: COMPLETED
})
commit consumer_native_transaction
return PROCESSED
The algorithm supplies atomic duplicate protection only for effects
and processing-ledger entries included within the consumer's native
transaction.
It does not by itself guarantee exactly-once execution of an external
nontransactional effect.
7.5.113. C-60.81 - Algorithm K: Outbox Worker Recovery
function RecoverOutboxProcessing(event_id):
event = NativeOutboxRegistry.get(event_id)
if event is unavailable:
return DENIED
if event.status == COMPLETED:
return COMPLETED
Das Expires 25 April 2027 [Page 317]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if event.status == PENDING:
return ELIGIBLE_FOR_VERIFIED_PROCESSING
if event.status == IN_PROGRESS:
result = QueryAuthoritativeDownstreamState(event)
if result == CONFIRMED_EFFECTED:
MarkOutboxCompleted(event) return COMPLETED
if result == CONFIRMED_NOT_EFFECTED:
return ELIGIBLE_FOR_RETRY
MarkEventIndeterminate(event)
return RECONCILIATION_REQUIRED
return APPLY_DEFINED_RECOVERY_POLICY
The system does not automatically retry an externally consequential
operation merely because the previous acknowledgment is missing.
C-60.82 - Algorithm L: Cross-Object Ownership Transfer
function TransferProtectedResourceOwnership(
resource_id, old_owner, new_owner, agent_context ):
transaction = NativeResourceEngine.beginSerializable()
resource = transaction.readForUpdate(resource_id)
if resource.owner != old_owner:
transaction.rollback() return DENIED
previous_index = transaction.readForUpdate(
OwnerIndex(old_owner) )
next_index = transaction.readForUpdate(
OwnerIndex(new_owner) )
transaction.update(resource_id, {
Das Expires 25 April 2027 [Page 318]
Internet-Draft Kernel-Hardware Execution Finality October 2026
owner: new_owner })
transaction.remove(previous_index, resource_id)
transaction.add(next_index, resource_id)
projected = transaction.readProjectedState({
resource_id, previous_index, next_index })
if not VerifyOwnershipRelationshipInvariant(projected):
transaction.rollback()
return DENIED
transaction.insertOutbox(
BuildOwnershipChangedEvent(projected) )
return transaction.commit()
This is one concrete implementation species of enforcement point(s)
61.
7.5.114. PART XIV - WORKED TECHNICAL EXAMPLES
C-60.83 - Example A: Protected Supplier Ownership Change
The following is a hypothetical implementation example.
An AI agent proposes transferring responsibility for a supplier
resource from Department A to Department B.
The native transaction stages:
1. Supplier owner update. 2. Department A index removal. 3.
Department B index addition. 4. Updated access relationship. 5.
Ownership-change outbox event.
The invariant evaluator checks that the supplier has exactly one
valid owner and that the associated indexes are consistent.
If all conditions succeed, the native transaction commits all
supported changes and the outbox record.
If the projected relationship is inconsistent, the entire transaction
is rejected.
Das Expires 25 April 2027 [Page 319]
Internet-Draft Kernel-Hardware Execution Finality October 2026
C-60.84 - Example B: Preventing Privileged Administrator Deletion
An enterprise resource must always have at least one active
privileged administrator.
Two AI agents concurrently attempt to remove different administrator
accounts.
Each transaction initially observes two active administrators.
Under insufficient snapshot-isolation handling, both removals might
appear valid separately.
The protected implementation uses serializable isolation or a shared
invariant lock.
Only one removal can commit under the invariant.
The other transaction is re-evaluated and rejected because it would
leave zero active administrators.
C-60.85 - Example C: Database Trigger Producing a Dependent Record
An agent requests modification of an account status.
The database's transaction-associated trigger creates a related
compliance record.
The projected state includes both the account update and the
compliance record.
The invariant evaluator checks that the new account status requires a
matching compliance record.
The transaction commits only if the combined state is valid.
C-60.86 - Example D: Transactional Notification Outbox
An agent updates a customer resource.
An authorized notification must be sent after successful commit.
The native transaction stages:
CUSTOMER UPDATE
x
Das Expires 25 April 2027 [Page 320]
Internet-Draft Kernel-Hardware Execution Finality October 2026
OUTBOX NOTIFICATION EVENT.
Both are committed together.
The notification worker reads only committed events.
If the customer update is rejected, no corresponding notification
event is committed.
The later external notification is processed separately and may
require its own idempotency and retry controls.
C-60.87 - Example E: Rejected Resource Update Does Not Emit Event
An AI agent requests a modification that violates a prohibited
resource transition.
The transaction-associated workflow would ordinarily generate an
event record.
The invariant evaluator rejects the projected state.
The native transaction rolls back.
Neither the resource modification nor the associated transactional
outbox event becomes committed.
The asynchronous worker therefore does not receive a committed event
representing the rejected change.
7.5.115. C-60.88 - Example F: Concurrent Quota Consumption
A resource group permits at most five active allocations.
Four allocations currently exist.
Two AI agents concurrently request one additional allocation.
The native transaction controller uses an invariant lock or
equivalent serializable mechanism.
One transaction commits the fifth allocation.
The second transaction is re-evaluated against the new committed
state and rejected.
The total remains within the protected limit.
Das Expires 25 April 2027 [Page 321]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.116. C-60.89 - Example G: Duplicate Outbox Event
A committed resource update generates an outbox event.
The worker processes the event.
Before acknowledging completion, the worker restarts.
The outbox dispatcher delivers the same event again.
The consumer's durable event ledger identifies the same event ID.
Where the consumer's effect and ledger are atomically coupled, the
duplicate does not repeat the corresponding native resource
modification.
7.5.117. C-60.90 - Example H: Resource-Version Consistency
An outbox event references Resource Version 41.
The resource subsequently advances to Version 42.
A worker receives the historical Version 41 event.
If the event represents an audit record, it may remain valid.
If it represents a latest-state synchronization operation, the policy
may require the worker to suppress or replace it.
The event-version rule distinguishes legitimate historical processing
from inconsistent stale processing.
7.5.118. C-60.91 - Example I: Protected Inventory Transfer
An AI agent requests transfer of inventory between two locations.
The transaction stages:
Source quantity decrease.
Destination quantity increase.
Transfer-record creation.
Outbox event creation.
The invariant evaluator checks that the source quantity does not
become negative and that the combined quantities remain consistent.
Das Expires 25 April 2027 [Page 322]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The transaction commits all changes or none.
7.5.119. C-60.92 - Example J: Trigger Dependency Cycle
A resource update activates a trigger.
The trigger updates another resource.
The second resource activates a trigger that would repeatedly modify
the first.
The engine detects an unsupported or unbounded dependency cycle under
the selected transaction rules.
The controller rejects the transaction rather than committing an
incompletely projected state.
C-60.93 - Example K: Agent Context Change During Transaction
An AI agent begins a resource modification under an authorized task.
Before commit, a relevant resource authority or ownership condition
changes.
The transaction controller detects the changed authorization
predicate through its selected concurrency mechanism.
The earlier projection is invalidated.
The operation is retried under current state or rejected.
7.5.120. C-60.94 - Example L: Outbox Dispatch Failure
An authorized resource update commits successfully with its required
outbox event.
The external notification service is unavailable.
The primary resource transaction remains committed.
The outbox event remains pending or retryable.
The worker later resumes processing under the defined event validity
and duplicate-control rules.
The system does not enforcement point that a failed external
notification rolls back the already committed primary resource
update.
Das Expires 25 April 2027 [Page 323]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.121. PART XV - FAILURE AND ADVERSARIAL CONDITIONS
7.5.122. C-60.95 - Representative Failure Cases
7.5.123. F1 - Primary-Only Authorization
A controller validates only the requested object modification.
Required dependent changes must also be included in the projected
state.
7.5.124. F2 - Missing Database Trigger
A transaction-associated trigger is omitted from the dependency
model.
The projected-state completeness condition fails.
7.5.125. F3 - Hidden Stored Procedure Mutation
A stored procedure modifies an additional resource object.
The relevant change must be represented or executed within the native
transaction before invariant evaluation.
7.5.126. F4 - Cross-Object Ownership Violation
A primary owner field changes without corresponding dependent
relationship updates.
The combined invariant rejects the transaction.
7.5.127. F5 - Invalid Aggregate State
The projected aggregate exceeds a permitted resource bound.
The transaction is rejected.
7.5.128. F6 - Prohibited State Transition
The operation attempts an invalid state-machine transition.
The native invariant evaluator rejects it.
7.5.129. F7 - Missing Authorization Scope
The requesting agent lacks authority for the projected resource
transition.
Das Expires 25 April 2027 [Page 324]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The transaction is rejected.
7.5.130. F8 - Trigger Recursion
A trigger creates an unresolved recursive dependency.
The native engine rejects or restricts the transaction according to
the defined bound.
7.5.131. F9 - External Side Effect Inside Transaction
A trigger attempts an irreversible external operation before commit.
The implementation routes the effect through the appropriate post-
commit mechanism or explicitly treats it as outside the native
atomicity guarantee.
7.5.132. F10 - Primary Commit Without Outbox
The primary resource update commits while a required event record is
omitted.
The atomic outbox design prevents this condition for transaction-
covered event creation.
7.5.133. F11 - Outbox Without Primary Commit
An event record becomes committed for a rejected primary mutation.
The shared native transaction prevents this inconsistency.
7.5.134. F12 - Outbox Event Identity Collision
Different events receive the same event identity.
The event identity scheme and uniqueness constraints prevent
accidental or unauthorized collision.
7.5.135. F13 - Duplicate Outbox Delivery
A dispatcher sends the same event more than once.
The worker applies the defined durable duplicate-control rule.
7.5.136. F14 - Resource-Version Mismatch
An event references a resource version inconsistent with the
originating committed transaction.
Das Expires 25 April 2027 [Page 325]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The worker rejects or reconciles it.
7.5.137. F15 - Legitimate Historical Event
The resource has advanced beyond an older event's version.
The worker applies the effect-class ordering rule rather than
automatically rejecting every older version.
7.5.138. F16 - Unauthorized Downstream Effect Class
An outbox record requests an operation outside its permitted effect
class.
The worker rejects it.
7.5.139. F17 - Concurrent Write Skew
Two transactions independently satisfy an invariant but jointly
violate it.
Serializable or equivalent shared-invariant protection prevents both
commits.
7.5.140. F18 - Lost Update
Two transactions attempt to overwrite the same resource state.
The native concurrency mechanism detects or serializes the conflict.
7.5.141. F19 - Phantom Predicate Conflict
An aggregate invariant depends upon a query result changed by a
concurrent insertion.
The implementation uses appropriate predicate protection rather than
only checking previously read row versions.
7.5.142. F20 - Stale Resource Version
A transaction relies upon a version superseded before commit.
The engine retries or rejects the affected projection.
7.5.143. F21 - Transaction Retry Reuses Old Approval
A conflicting transaction retries using an outdated invariant result.
Das Expires 25 April 2027 [Page 326]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The system reconstructs and re-evaluates the projection.
7.5.144. F22 - Retry Exhaustion
Repeated serialization conflicts exceed the configured retry bound.
The operation is rejected or returned for later authorized retry.
7.5.145. F23 - Transaction Timeout
A projected-state transaction exceeds supported execution limits.
The engine rolls back or applies its defined failure procedure.
7.5.146. F24 - Outbox Worker Crash
A worker fails after receiving an event.
The durable outbox and consumer state support appropriate recovery.
7.5.147. F25 - Lost External Acknowledgment
An external operation may have occurred but no acknowledgment is
available.
The system records an indeterminate outcome and does not blindly
assume non-effectuation.
7.5.148. F26 - Duplicate External Payment or Message
A nontransactional destination may execute a repeated operation
twice.
The architecture requires suitable destination idempotency or
reconciliation for any claimed duplicate-prevention guarantee.
7.5.149. F27 - Resource-State Rollback
An earlier database state is restored.
The recovery procedure reconciles committed transaction and outbox
generations according to the selected durability model.
7.5.150. F28 - Unauthorized Trigger Modification
An attacker alters a resource rule.
Das Expires 25 April 2027 [Page 327]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The applicable trusted configuration and transaction policy identify
or prevent unauthorized rule changes.
7.5.151. F29 - New Trigger Introduced
A new transaction-associated trigger modifies additional state.
The native projection must include its effects under the current
resource configuration.
7.5.152. F30 - Outbox Processing Out of Order
Events are delivered in a different order from resource commits.
The consumer applies its resource-version and ordering policy.
7.5.153. F31 - Incomplete Distributed Transaction
Related resource objects reside in different databases without shared
atomicity.
The implementation does not falsely enforcement point one native
atomic transaction across unsupported domains.
7.5.154. F32 - Snapshot Isolation Insufficient
An implementation uses snapshot isolation without protection for
shared invariants.
The missing predicate or aggregate conflict control must be supplied.
7.5.155. F33 - Wrong Agent Context
A mutation is attributed to another agent's authority.
The resource engine rejects the invalid context.
7.5.156. F34 - Outbox Payload Substitution
An event payload is modified after commitment.
The required transaction-state or event-integrity checks detect the
change.
7.5.157. F35 - Native Engine Unavailable
The resource engine cannot establish a valid transaction.
Das Expires 25 April 2027 [Page 328]
Internet-Draft Kernel-Hardware Execution Finality October 2026
No speculative resource change is committed.
7.5.158. F36 - Invariant Evaluator Failure
A mandatory invariant cannot be evaluated.
The transaction remains uncommitted or is rejected.
7.5.159. F37 - Atomic Commit Outcome Unknown
The client loses the commit response.
The system queries authoritative transaction state before repeating
the logical operation.
7.5.160. F38 - Compensating Action Confused With Rollback
An already committed external effect requires later compensation.
The system distinguishes compensation from native rollback.
7.5.161. PART XVI - IMPLEMENTATION VARIATIONS
7.5.162. C-60.96 - Relational Database Implementation
The resource engine uses ACID transactions, constraints, stored
procedures, triggers, and transactional outbox tables.
Serializable isolation or appropriate invariant-specific locking
protects concurrent operations.
7.5.163. C-60.97 - Transactional Document Database
A document database with native multi-document transactions stages
changes to several related documents.
The invariant evaluator checks their combined prospective state.
The transaction commits or rejects all covered mutations.
7.5.164. C-60.98 - Transactional Key-Value Engine
A versioned key-value system uses conditional writes or an atomic
transaction API.
Resource state and outbox records are committed under the supported
transactional consistency model.
Das Expires 25 April 2027 [Page 329]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.165. C-60.99 - Enterprise Resource Management
An enterprise application uses native resource transactions to
protect related ownership, account, compliance, or allocation
records.
| Agent-originating operations are associated with authenticated task identities. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-60.100 - Financial Workflow Resource Engine A financial workflow database evaluates projected ledger, approval, ownership, or transaction state under applicable invariants. Any later external settlement remains governed by the separately defined settlement architecture. |
| C-60.101 - Cloud Configuration Database An AI agent requests infrastructure configuration changes. A native resource database projects related configuration objects and dependent event records. The transaction commits only when the resulting state satisfies defined consistency and authorization constraints. |
| C-60.102 - Native Resource Outbox Worker The resource engine commits event records atomically with resource changes. A downstream worker verifies event identity, resource version, and permitted effect class before executing corresponding work. |
7.5.166. C-60.103 - Multi-Agent Concurrency
Multiple AI-agent identities submit transactions to the same resource
engine.
The native transaction controller serializes or rejects conflicting
proposals to maintain shared invariants.
7.5.167. C-60.104 - Optimistic Concurrency Variation
The system uses resource-version comparison and transaction restart
after conflicts.
| Additional predicate or aggregate protection is supplied where required. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-60.105 - Pessimistic Concurrency Variation The system obtains shared-invariant locks covering relevant objects or predicates. Transactions retain those locks through commit or rollback. |
| C-60.106 - Distributed Serializable Resource Engine A distributed database with appropriate serializable transaction support implements the projection, invariant checks, and atomic outbox records. The guarantees are limited to the engine's actual transaction domain. |
| C-60.107 - Optional DAS Protected Finality Integration The native resource engine may be combined with separate protected validation evidence, scoped finality capabilities, and an external or integrated Finality Sink. Such integration can provide additional execution-boundary authorization. However, the independent native projected-state claim does not depend upon these separate artifacts. |
7.5.168. PART XVII - REPRESENTATIVE DATA STRUCTURES
7.5.169. C-60.108 - AgentResourceOperationRecord
Fields may include:
1. LogicalOperationID. 2. AgentContextID.
3. 4. 5. 6. 7. 8. 9.
TaskID. ResourceClass. RequestedMutation. TargetResourceIDs.
NativeAuthorityReference. OperationGeneration. OperationStatus.
7.5.170. C-60.109 - NativeTransactionRecord
Fields may include:
Das Expires 25 April 2027 [Page 330]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. TransactionID. 2. LogicalOperationID. 3. IsolationLevel. 4.
SnapshotReference. 5. ReadSetReference. 6. WriteSetReference. 7.
PredicateSetReference. 8. TransactionStatus. 9.
CommitSequenceReference.
7.5.171. C-60.110 - ProspectiveResourceStateRecord
Fields may include:
1. ProjectionID. 2. TransactionID. 3. BaseResourceVersions. 4.
PrimaryChangeSet. 5. DependentChangeSet. 6. ProjectedObjectStates.
7. RequiredOutboxReferences. 8. ProjectionGeneration. 9.
ProjectionCompletenessStatus.
7.5.172. C-60.111 - ResourceDependencyRecord
Fields may include:
1. DependencyID. 2. OriginatingOperationClass. 3.
TriggerOrRuleIdentity. 4. DependentResourceClass.
5. GeneratedTransitionClass. 6. ConditionalPredicate. 7.
TransactionAssociation. 8. DependencyVersion. 9. DependencyStatus.
7.5.173. C-60.112 - ResourceInvariantRecord
Fields may include:
1. InvariantID. 2. InvariantClass. 3. RelevantResourceClasses. 4.
ReadDomainPredicate. 5. ConstraintExpression. 6.
RequiredIsolationSemantics. 7. ViolationDisposition. 8.
PolicyGeneration. 9. InvariantStatus.
7.5.174. C-60.113 - CrossObjectInvariantRecord
Fields may include:
1. RelationshipID. 2. PrimaryResourceID. 3. DependentResourceIDs.
4. RequiredRelationshipPredicate. 5. BaseVersionReferences. 6.
ProjectedVersionReferences. 7. EvaluationOutcome. 8.
TransactionReference.
7.5.175. C-60.114 - TransactionalOutboxRecord
Fields may include:
1. OutboxEventID. 2. 3. 4. 5. 6. 7.
Das Expires 25 April 2027 [Page 331]
Internet-Draft Kernel-Hardware Execution Finality October 2026
LogicalOperationID. TransactionID. ResourceID.
CommittedResourceVersion. PermittedDownstreamEffectClass.
DestinationOrResourceScope.
8. EventPayloadReference. 9. EventStatus. 10.
DeliveryAttemptCount.
7.5.176. C-60.115 - ConsumerEventLedgerRecord
Fields may include:
1. ConsumerID. 2. OutboxEventID. 3. LogicalOperationID. 4.
ResourceVersionReference. 5. EffectClass. 6.
LocalProcessingTransactionID. 7. CompletionStatus. 8.
CompletionReference.
7.5.177. C-60.116 - ConcurrentConflictRecord
Fields may include:
1. ConflictID. 2. TransactionA. 3. TransactionB. 4.
SharedInvariantID. 5. ConflictingResourceReferences. 6.
ConflictingPredicateReference. 7. ObservedVersionMismatch. 8.
ResolutionAction. 9. RetryGeneration.
7.5.178. C-60.117 - NativeCommitOutcomeRecord
Fields may include:
1. 2. 3. 4. 5. 6. 7. 8.
TransactionID. LogicalOperationID. CommitOutcome.
CommittedResourceVersions. OutboxEventReferences.
CommitSequenceReference. ConflictStatus. RecoveryStatus.
These structures may be implemented through database tables, native
resource metadata, transaction logs, transactional document
collections, or equivalent resource-engine facilities.
7.5.179. PART XVIII - ENGINEERING VERIFICATION
7.5.180. C-60.118 - Proposed Test Matrix
The following tests are proposed and are not representations of
completed experiments.
Das Expires 25 April 2027 [Page 332]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.5.181. Test Condition
T1 Valid projected state T2 Invalid object integrity T3 Invalid field
relationship T4 Invalid ownership change T5 Prohibited state
transition T6 Aggregate bound exceeded T7 Primary modification
triggers dependent
update T8 Trigger creates outbox event T9 Primary transaction
rejected T10 Dependent modification fails T11 Cross-object
relationship valid T12 Cross-object relationship invalid T13 Two
concurrent operations violate shared
invariant T14 Serializable conflict T15 Optimistic version conflict
T16 Predicate phantom conflict T17 Write-skew scenario T18 Concurrent
quota increment T19 Native lock conflict T20 Retry under new snapshot
T21 Retry limit exceeded T22 Transaction timeout T23 Outbox record
references committed
resource version T24 Duplicate event delivery T25 Outbox event with
wrong resource version T26 Legitimate historical event T27 Outbox
event with unauthorized effect class Rejected T28 Worker crashes
before effect
7.5.182. Expected result
Transaction commits Transaction rejected Transaction rejected
Transaction rejected Transaction rejected Transaction rejected
Combined state evaluated Event atomically committed Outbox event not
committed Primary change rolled back Combined transaction commits
Transaction rejected At least one rejected or re-evaluated
Transaction retried or rejected Stale projection rejected Aggregate
invariant protected Combined invariant preserved Limit maintained
Required serialization enforced Invariants recomputed No unsafe
commit Uncommitted changes rolled back Version verified Duplicate
effect controlled Rejected or reconciled Effect-specific version rule
applied
Recoverable pending state
T29 Worker crashes after local transactional
effect T30 Lost external acknowledgment T31 Outbox event reordered
T32 Unauthorized trigger introduced T33 Trigger cycle T34 Incomplete
projection T35 External call attempted within speculative
transaction T36 Agent authority invalid T37 Resource ownership
changed concurrently T38 Resource state restored from stale snapshot
T39 Distributed transaction unsupported T40 Commit response lost T41
Das Expires 25 April 2027 [Page 333]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Multi-agent concurrent ownership transfer T42 Outbox creation fails
T43 Database trigger updates aggregate object T44 Trigger-created
event after nested mutation T45 Event payload tampered T46 Resource
version advances after event
creation T47 Consumer duplicate ledger fails to commit T48 Native
transaction service unavailable
Durable duplicate ledger prevents repeat Indeterminate state retained
Ordering policy enforced Current dependency configuration verified
Native bound or rejection Commit withheld Nontransactional boundary
correctly handled Native transaction rejected Authorization re-
evaluated Required continuity and conflict checks applied No false
atomicity enforcement point Authoritative commit state queried
Combined state remains valid Primary transaction not committed
Aggregate invariant checked Required dependency closure evaluated
Required integrity or transaction-state check fails Defined
historical/latest semantics applied Effect and ledger transaction
outcome reconciled No speculative state committed
Concrete tests should specify the database engine, isolation level,
schema, transactionassociated rules, concurrent schedules, invariant
predicates, resource versions, expected outbox entries, and observed
commit or rollback outcomes.
7.5.183. PART XIX - Enforcement-Point Mapping and Technical
Correspondence
7.5.184. C-60.119 - Independent enforcement point(s) 60
The embodiment provides the following mapping.
enforcement point(s) 60(a): Native resource engine receiving AI-
agent-initiated resource mutations.
enforcement point(s) 60(b): Isolated prospective resource-state
representation maintained through native
transaction facilities.
enforcement point(s) 60(c): Dependency evaluator identifying trigger,
procedure, resource-rule, and
transaction-associated event effects.
enforcement point(s) 60(d): Projected-state generator combining
primary and applicable dependent
Das Expires 25 April 2027 [Page 334]
Internet-Draft Kernel-Hardware Execution Finality October 2026
changes.
enforcement point(s) 60(e): Invariant evaluator checking object
integrity, field consistency, ownership,
authorization, aggregate bounds, and prohibited state transitions.
enforcement point(s) 60(f): Native transaction controller committing
or rejecting according to invariant
evaluation.
enforcement point(s) 60(g): Atomic association of accepted resource
changes with required transactional
outbox entries.
enforcement point(s) 60(h): Rollback of both primary changes and
corresponding outbox entries following
rejection.
enforcement point(s) 60(i): Detection of concurrent changes
invalidating projected state, followed by re-
evaluation or rejection.
First concluding requirement: Authorization occurs as part of the
native resource
transaction.
Second concluding requirement: The resource engine may operate
without separately
committed validation receipts or separately transferable effectuation
capabilities.
7.5.185. C-60.120 - Dependent enforcement point(s) 61: Cross-Object
Modification
The embodiment provides:
Das Expires 25 April 2027 [Page 335]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Primary resource objects. 2. Dependent resource objects. 3.
Transaction-local multi-object changes. 4. Inter-object relationship
predicates. 5. Ownership-index consistency. 6. Shared aggregate
objects. 7. Cross-object invariant evaluation. 8. Atomic commit or
rejection within the supported transaction domain. 9. Concurrent
relationship protection. 10. Worked ownership-transfer
implementation.
C-60.121 - Dependent enforcement point(s) 62: Transactional Outbox
Consistency
The embodiment provides:
1. Atomic outbox record creation. 2. Committed resource-version
references. 3. Permitted downstream effect classes. 4. Stable event
identity. 5. Durable event-processing ledger. 6. Duplicate-event
detection. 7. Resource-version consistency checks. 8. Historical
versus latest-state event semantics. 9. Retry and recovery handling.
10. Distinction between native atomicity and external downstream
effectuation.
C-60.122 - Dependent enforcement point(s) 63: Concurrent Transaction
Conflict
The embodiment provides:
1. Multiple concurrent agent transactions. 2. Projected resource
states. 3. Shared resource invariants. 4. Serializable transaction
controls. 5. Optimistic resource-version validation. 6. Predicate
conflict handling. 7. Shared-invariant locking. 8. Write-skew
prevention. 9. Conflict-triggered re-evaluation. 10. Transaction
rejection where the combined committed state would violate the
invariant.
7.5.186. PART XX - implementer IMPLEMENTATION REQUIREMENTS
7.5.187. C-60.123 - Implementation Checklist
A person having ordinary skill in the art implementing the embodiment
identifies:
Das Expires 25 April 2027 [Page 336]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. The native resource engine. 2. Its supported transaction
isolation levels. 3. Its transaction durability semantics. 4. The
agent-originating request interface. 5. The authenticated agent and
task context. 6. The canonical state-modifying operation descriptor.
7. The affected resource objects. 8. The applicable resource-
version scheme. 9. The transaction read set. 10. The transaction
write set. 11. The transaction-associated trigger definitions. 12.
The applicable stored procedures. 13. The resource rules.
14. The dependency evaluation ordering. 15. The nested trigger
handling. 16. The projected-state representation. 17. The required
object integrity constraints. 18. The required field consistency
rules. 19. The ownership and authorization invariants. 20. The
aggregate resource bounds. 21. The prohibited state-transition
rules. 22. The cross-object relationship predicates. 23. The
invariant read-domain requirements. 24. The native transaction
commit controller. 25. The rollback procedure. 26. The
transactional outbox schema. 27. The event identity-generation
procedure. 28. The committed resource-version binding. 29. The
permitted downstream effect classes. 30. The outbox worker. 31. The
event deduplication procedure. 32. The event ordering and version-
consistency rules. 33. The outbox recovery policy. 34. The handling
of unknown external completion. 35. The shared-invariant concurrency
protection. 36. The serializable or equivalent predicate validation.
37. The conflict detection procedure. 38. The transaction retry
algorithm. 39. The transaction retry resource bounds. 40. The
handling of incomplete dependency projection. 41. The treatment of
external side effects inside triggers. 42. The distributed
transaction-domain limitations. 43. The durability and recovery
guarantees. 44. The tests demonstrating native atomicity and
invariant preservation.
A resource engine implementing this embodiment must enforce the
stated properties using actual supported transaction facilities.
A preliminary API approval, audit log, or post-commit compliance scan
does not by itself supply the transaction-native combined projected-
state authorization required by the enforcement points.
7.5.188. C-60.124 - Technical Effect
The disclosed system enables an artificial-intelligence-agent-
associated resource operation to be authorized according to the
combined resource state that would result from its execution.
The native resource engine constructs an isolated prospective state
comprising the primary modification and applicable transaction-
associated dependent changes.
Das Expires 25 April 2027 [Page 337]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Machine-enforced resource invariants are evaluated before the
transaction commits.
The native transaction controller prevents commitment of an invalid
combined state.
Required transactional outbox entries are atomically associated with
accepted resource modifications, preventing the outbox from
representing rejected primary changes within the supported
transaction boundary.
Concurrent conflict detection prevents competing agent operations
from committing a combined state that violates a shared invariant.
The architecture supports resource-native authorization without
mandating a separately committed receipt or transferable finality
capability.
Its guarantees depend upon the actual isolation, trigger,
transactional outbox, concurrency, and durability semantics supplied
by the selected resource engine.
7.5.189. C-60.125 - Technical Summary
this implementation profile discloses a computer-implemented native
resource-state protection system for artificial-intelligence-agent-
initiated operations.
A Native Resource Engine receives a proposed state-modifying
operation and establishes an isolated prospective resource
representation through a supported transaction-state mechanism.
A Dependency Evaluator identifies applicable database triggers,
stored procedures, resource rules, and transaction-associated event
effects.
A Projected-State Generator determines the combined prospective state
produced by the primary operation and its dependent modifications.
An Invariant Evaluator compares the combined state with machine-
enforced integrity, field consistency, ownership, authorization,
aggregate mutation, and prohibited-transition constraints.
A Native Transaction Controller commits or rejects the modification
according to the invariant evaluation.
Required transactional outbox records are committed atomically with
the accepted primary resource changes.
Das Expires 25 April 2027 [Page 338]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Rejection prevents both the invalid primary changes and corresponding
transactional outbox entries from becoming committed.
A concurrency-control mechanism detects modifications that invalidate
the previously projected state and causes re-evaluation,
serialization, or rejection.
A downstream event worker verifies committed resource-version
references, permitted effect classes, and event identities before
processing eligible outbox records.
The system thereby provides transaction-native authorization and
consistency protection for direct and transaction-associated indirect
effects of AI-agent operations.
The architecture is independently implementable through the native
resource engine without requiring a separate DAS validation receipt
or scoped finality capability.
7.5.189.1. POST-EFFECT CAUSAL CONTAINMENT AND SELECTIVE REMEDIATION OF
ARTIFICIAL-INTELLIGENCE-AGENT OPERATIONS USING CROSS-SERVICE
7.5.189.2. EFFECT LINEAGE, CONFLICT-PRESERVING STATE RECONSTRUCTION,
DEPENDENCY-ORDERED CORRECTION, IRREVERSIBILITY
7.5.189.3. CLASSIFICATION, AND VERIFIED RECOVERY
7.6. Implementation Profile C-76
Source location: original disclosure pages 1322-1396. Source
technical content is presented here for implementation analysis;
numbering reflects the original profile family rather than a
requirement to implement every profile.
END OF EMBODIMENT C-72 EMBODIMENT C-76 HARDWARE-RESIDENT DEFERRED-
EFFECT BUDGET ACCOUNTING FOR ARTIFICIAL-INTELLIGENCE-AGENT WORKLOADS
USING PROTECTED
QUEUE-ADMISSION RESERVATIONS, TASK-BOUND RESOURCE-EFFECT METERS,
ATOMIC COMPLETION RECONCILIATION, DELEGATED COMMAND AGGREGATION, AND
RESET-SAFE HARDWARE QUEUE
7.6.1. CONTINUITY
Das Expires 25 April 2027 [Page 339]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.2. C-76.1 - Technical Field
this implementation profile relates to computer security, hardware-
assisted resource governance, artificial-intelligence-agent
execution, programmable network interfaces, directmemory-access
control, input/output memory management, accelerator command queues,
hardware resource budgeting, protected accounting registers, and
persistent authorization state.
More particularly, the embodiment discloses a hardware-assisted
resource-control system configured to receive resource-operation
commands attributable to an artificial-intelligenceagent workload;
determine a bounded quantity of consequential resource effects
associated with each command; reserve that quantity in a hardware-
protected accounting structure before admitting the command to an
effect-capable queue; and reconcile reserved and completed quantities
when commands execute, partially execute, fail, or become verifiably
incapable of further effectuation.
The system may operate at a network adapter, SmartNIC, data-
processing unit, storage controller, DMA controller, accelerator
queue manager, peripheral interface, IOMMUassociated admission
service, or another hardware-adjacent resource-operation boundary.
The architecture may implement budget enforcement independently of a
portable, percommand authorization receipt or separately issued
finality capability.
7.6.3. PART I - TECHNICAL PROBLEM
7.6.4. C-76.2 - Software Authorization Can Precede Physical
Effectuation
An artificial-intelligence agent may submit commands to an operating
system or resource controller.
The commands may be accepted into:
1. Network transmission queues. 2. Storage command rings. 3. DMA
descriptor queues. 4. Accelerator execution queues. 5. Device
command buffers. 6. Peripheral operation queues. 7. Host-to-device
shared memory. 8. Asynchronous I/O submission rings. 9. Virtual-
function queues. 10. Device-managed work schedulers.
Once accepted, a command may execute independently of the original
agent process.
Das Expires 25 April 2027 [Page 340]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The originating process may terminate, be restarted, or lose its
software entitlement while the command remains capable of producing a
physical or externally consequential effect.
7.6.5. C-76.3 - Pending Commands as Future Effect Liability
Consider an agent authorized to transmit at most one specified
quantity of data through a controlled network interface.
The agent may submit multiple transmission descriptors before any
have completed.
If accounting increments only after hardware completion, the agent
may submit more commands than the available effect budget permits.
The total completed effect may later exceed the intended limit.
The disclosed system therefore reserves effect capacity before a
command enters the relevant executable queue.
7.6.6. C-76.4 - Multi-Process Budget Circumvention
An agent may create:
(a) child processes; (b) delegated workers; (c) separate container
processes; (d) concurrent host threads; (e) multiple accelerator
streams; (f) multiple network transmit rings; (g) several virtual-
function contexts; or (h) additional submission contexts.
If each context receives an independently reset budget, the
originating task can potentially exceed the intended aggregate effect
limit.
The embodiment associates the commands with a common protected task-
accounting domain.
7.6.7. C-76.5 - Cancellation Does Not Necessarily Stop Effectuation
A host may issue:
CANCEL COMMAND.
However, the device may already have:
Das Expires 25 April 2027 [Page 341]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Fetched a descriptor. 2. Transmitted part of a packet sequence.
3. Written a portion of a storage extent. 4. Completed a DMA burst.
5. Submitted work to a downstream engine. 6. Transferred command
ownership to another queue. 7. Continued executing after a
cancellation acknowledgment was initiated.
The accounting controller cannot release all reserved capacity merely
because the host requested cancellation.
It must establish which portion of the command has already effected a
resource change and whether the remaining portion can still complete.
7.6.8. C-76.6 - Reset and Snapshot Replay
A host may restart and restore an earlier software state.
A virtual machine may be resumed from a snapshot.
An accelerator controller may reset.
A queue may fail over to another device.
If the effect-budget table is restored to an earlier value while
previously submitted commands remain executable, the same budget may
be consumed more than once.
this implementation profile includes protected continuity, fencing,
and reconciliation rules.
7.6.9. C-76.7 - Device-Level Concurrency
Commands from several host processes may arrive through independent
queue pairs.
An ordinary software counter may not atomically coordinate all
submissions.
For example:
Remaining budget = 1 operation.
Queue A submits one operation.
Queue B simultaneously submits one operation.
Both queue processors observe the same unused budget.
If both are admitted, the budget is exceeded.
Das Expires 25 April 2027 [Page 342]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The hardware-adjacent admission controller therefore uses an atomic
reservation mechanism shared across the applicable queues.
7.6.10. C-76.8 - Different Resource Effect Classes
A system may govern:
NETWORK_TRANSMISSION_BYTES.
PERSISTENT_STORAGE_WRITES.
DMA_WRITE_BYTES.
ACCELERATOR_EGRESS_BYTES.
PERIPHERAL_COMMAND_COUNT.
PRIVILEGED_DEVICE_OPERATIONS.
RESOURCE_MUTATION_COUNT.
The meaning of a completed effect differs among these classes.
Network transmission by a NIC is not automatically proof of remote
delivery.
A DMA write may be effective when it reaches the protected target
memory domain.
A storage write may have separate issued, accepted, and durable-
completion stages.
The implementation defines the measured effect boundary for each
class.
7.6.11. PART II - CENTRAL TECHNICAL PRINCIPLE
7.6.12. C-76.9 - Pre-Queue Reservation
The principal mechanism is:
A resource-operation command cannot enter an effect-capable hardware
queue unless the applicable effect-budget capacity has already been
reserved against its originating task.
The reservation remains outstanding while the command can produce an
effect.
Das Expires 25 April 2027 [Page 343]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A verified completed portion is transferred to completed-effect
accounting.
A remaining portion is released only after the controller establishes
that it cannot subsequently produce the corresponding effect.
7.6.13. C-76.10 - Principal Accounting Invariant
For task context t and effect class e:
B(t,e) = authorized effect-budget limit.
C(t,e) = completed effect quantity.
R(t,e) = reserved outstanding-effect quantity.
The invariant is:
C(t,e) + R(t,e) ≤ B(t,e).
Admission of a new command having bounded exposure q requires:
C(t,e) + R(t,e) + q ≤ B(t,e).
The controller atomically establishes this condition and increases R
by q before making the command effect-capable.
7.6.14. C-76.11 - Typed Effect Dimensions
The budget may be represented as a vector:
B(t) = (B₁, B₂, …, Bₙ).
Corresponding protected accounting state comprises:
C(t) = (C₁, C₂, …, Cₙ).
R(t) = (R₁, R₂, …, Rₙ).
The admission controller checks the applicable dimensions.
A command may consume multiple dimensions.
For example, a network transmission may contribute to:
NetworkBytes.
TransmissionCommandCount.
Das Expires 25 April 2027 [Page 344]
Internet-Draft Kernel-Hardware Execution Finality October 2026
DestinationSpecificBytes.
The quantities are not combined without defined compatible units.
7.6.15. C-76.12 - Reservation Conservation
For a command initially assigned reservation q:
q = completed_quantity + remaining_reserved_quantity +
verifiably_released_quantity,
subject to any separately recorded adjustment authorized by the
selected accounting semantics.
At any time, the controller must not count the same completed
quantity as both available headroom and canceled unused capacity.
Where the outcome is uncertain, the corresponding quantity remains
charged as completed or reserved according to a conservative policy.
7.6.16. C-76.13 - Command Inertness Before Admission
Before successful reservation, a command may exist in host memory or
a protected staging buffer.
It must not be executable through the governed hardware queue.
The command becomes eligible for effectuation only after the
admission controller commits the applicable accounting reservation.
7.6.17. C-76.14 - Enforcement Without Portable Per-Command Receipt
The controller may enforce the command using:
1. A protected budget table. 2. Queue-local admission state. 3.
Task association. 4. Protected command descriptors. 5. Atomic
accounting. 6. Device-local command state. 7. Relevant resource
limits.
The host need not receive a portable per-command validation receipt.
Nor must it possess a separately issued non-bearer finality
capability for each command.
This differentiates the present mechanism from other DAS execution-
finality embodiments, while allowing optional integration with them.
Das Expires 25 April 2027 [Page 345]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.18. PART III - PRINCIPAL SYSTEM COMPONENTS
7.6.19. C-76.15 - AI-Agent Host Execution Environment
The host environment may include an agent runtime, sandbox,
container, virtual machine, process, or delegated worker.
The environment generates commands destined for a hardware resource
interface.
The host-side component may be untrusted or less trusted than the
protected accounting controller.
7.6.20. C-76.16 - Task-Context Association Mechanism
A Task-Context Association Mechanism binds submitted commands to a
machine-readable task identity.
A representative association comprises:
TaskID.
RootAgentID.
ExecutionContextID.
DelegatedContextID.
AuthorityGeneration.
EffectClass.
BudgetDomainID.
The command's task identity must be established through a controlled
mechanism, not solely a freely editable descriptor field supplied by
the agent.
7.6.21. C-76.17 - Hardware-Adjacent Admission Controller
The admission controller mediates the transition from non-executable
staging into an effectcapable hardware queue.
It may reside:
Das Expires 25 April 2027 [Page 346]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) in NIC firmware; (b) in a SmartNIC processor; (c) in a DPU
control plane; (d) in a device queue manager; (e) in a trusted host-
to-device submission controller; (f) in an accelerator runtime
protected by appropriate device isolation; (g) in a storage
controller; or (h) in a suitably protected I/O admission domain.
The selected location must provide effective control over the
governed queue-admission path.
7.6.22. C-76.18 - Hardware-Protected Accounting Table
The accounting table includes entries indexed by task and effect
class.
A representative entry comprises:
TaskID = TASK-204.
EffectClass = NETWORK_TX_BYTES.
BudgetLimit = 1,048,576.
ReservedOutstanding = 262,144.
CompletedEffects = 524,288.
AuthorityGeneration = 17.
AccountingGeneration = 301.
The values are illustrative quantities in bytes.
7.6.23. C-76.19 - Effect Quantity Estimator
An Effect Quantity Estimator determines an estimated or bounded
resource-effect quantity associated with a command.
It may examine:
1. Command type. 2. Descriptor length. 3. Number of scatter-gather
entries. 4. Transfer size. 5. Maximum permitted repetitions. 6.
Destination count. 7. Accelerator output size. 8. Storage block
count. 9. Resource operation cardinality. 10. Queue execution
parameters.
The admission decision uses a bound sufficient for the selected
enforcement guarantee.
Das Expires 25 April 2027 [Page 347]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.24. C-76.20 - Atomic Reservation Engine
An Atomic Reservation Engine coordinates admission against the
protected budget table.
It implements an indivisible operation that:
1. Reads the applicable budget state. 2. Verifies available
capacity. 3. Adds the required reservation. 4. Records the command
reservation association. 5. Commits the updated accounting
generation.
Only successful reservation permits queue admission.
7.6.25. C-76.21 - Effect-Capable Queue
An Effect-Capable Queue contains commands that the hardware may
execute.
Examples include:
NIC transmit rings.
DMA submission queues.
Storage operation queues.
Accelerator work queues.
Peripheral command rings.
The queue may have multiple producers and execution engines.
7.6.26. C-76.22 - Command-Execution Controller
The Command-Execution Controller determines whether a submitted
command is admitted, executed, deferred, canceled, or rejected.
It ensures that a command does not bypass the reservation
requirement.
7.6.27. C-76.23 - Hardware Completion Observer
A Hardware Completion Observer identifies authoritative evidence of
resource effectuation or command completion.
Possible sources include:
Das Expires 25 April 2027 [Page 348]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) device completion records;
(b) hardware byte counters;
(c) DMA transaction completion state;
(d) storage-controller acknowledgments;
(e) protected queue ownership transitions;
(f) accelerator execution completion records;
(g) resource-specific effect counters.
The observation must correspond to the defined effect boundary.
7.6.28. C-76.24 - Completion-Reconciliation Engine
The Completion-Reconciliation Engine updates protected accounting
following:
COMPLETION.
PARTIAL_COMPLETION.
VERIFIED_CANCELLATION.
FAILURE.
INDETERMINATE_EXECUTION.
QUEUE_RECOVERY.
It distinguishes quantities already effected from quantities that
remain capable of future effectuation.
7.6.29. C-76.25 - Delegation-Accounting Controller
The Delegation-Accounting Controller associates subordinate execution
contexts with an originating task budget.
The mechanism may maintain:
ParentTaskID.
ChildExecutionContextID.
DelegationGeneration.
Das Expires 25 April 2027 [Page 349]
Internet-Draft Kernel-Hardware Execution Finality October 2026
SharedBudgetReference.
PermittedEffectClasses.
DelegationStatus.
7.6.30. C-76.26 - Recovery and Queue-Continuity Controller
A Recovery Controller coordinates:
1. Host restart. 2. Device reset. 3. Queue reconstruction. 4.
Controller failover. 5. VM migration. 6. Persisted budget recovery.
7. Outstanding command identification. 8. Prior reservation
reconciliation. 9. Stale submission prevention.
7.6.31. C-76.27 - Protected Configuration Authority
A Protected Configuration Authority establishes authorized task
budgets and effect classes.
It may be a privileged host service, trusted firmware control path,
device management service, or another authenticated budget-
provisioning authority.
The agent cannot arbitrarily increase its own budget by writing to
the accounting table.
7.6.32. PART IV - TRUST AND ENFORCEMENT BOUNDARIES
7.6.33. C-76.28 - Host-Controller Separation
The host may generate arbitrary commands.
The admission controller determines whether the commands may enter
the governed effectcapable queue.
The host does not obtain unrestricted write access to:
(a) budget limits; (b) reserved counters; (c) completed counters; (d)
command-reservation identities; (e) delegation accounting; (f)
accounting generations; or (g) recovery state.
7.6.34. C-76.29 - Meaning of Hardware Protection
The phrase hardware-protected accounting may refer to an
implementation in which:
Das Expires 25 April 2027 [Page 350]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. Device firmware controls table modification. 2. Memory regions
are inaccessible to unauthorized host contexts. 3. A trusted
controller mediates counter updates. 4. Hardware access-control
registers restrict writes. 5. Protected SRAM or device-local memory
stores accounting state. 6. An appropriately isolated management
processor maintains authoritative counters.
The required protection is against unauthorized alteration by the
agent and relevant lesstrusted host execution contexts.
The enforcement point does not require all implementations to use the
same secure-memory technology.
7.6.35. C-76.30 - Host-Controlled Descriptor Risk
A command descriptor may contain a claimed TaskID.
If the host can freely substitute another task's identity, it may
evade the intended budget.
The controller therefore uses an authenticated or protected context-
to-task association.
Possible bindings include:
(a) device submission queue identity; (b) PASID-associated process
context; (c) virtual-function identity;
(d) protected queue ownership;
(e) host-authenticated control-plane assignment;
(f) device-local execution context;
(g) another enforced task mapping.
7.6.36. C-76.31 - Device Queue Isolation
The controller must prevent commands from entering an effect-capable
queue outside its admission path where that queue falls within the
claimed governed effect domain.
For example, a network device with several transmit rings may require
common budget enforcement across the relevant rings.
A reservation mechanism protecting only one ring does not
automatically govern another unrestricted ring.
Das Expires 25 April 2027 [Page 351]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.37. C-76.32 - Multiple Physical Paths
A task may have access to:
NIC A.
NIC B.
DMA engine C.
An application-specific command interface D.
The budget controller must define which paths contribute to the
protected aggregate.
Where a shared budget governs several physical paths, appropriate
cross-controller accounting or disjoint allocated sub-budgets are
required.
A controller cannot guarantee a global effect cap if material
uncontrolled alternative paths remain available.
7.6.38. PART V - TASK AND DELEGATION IDENTITY
7.6.39. C-76.33 - Root Task Identity
A Root Task ID identifies the original AI-agent task whose resource
effects are governed.
For example:
RootTaskID = TASK-204.
The identifier is allocated or authenticated by the trusted task-
control authority.
7.6.40. C-76.34 - Execution Context Identity
An Execution Context may represent:
1. A process. 2. A thread group. 3. A container. 4. A virtual
machine. 5. A GPU context. 6. A NIC queue owner. 7. A delegated
worker. 8. A device virtual function.
Each context receives an association with its authorized task.
Das Expires 25 April 2027 [Page 352]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.41. C-76.35 - Parent-Child Delegation
A representative delegation structure is:
ROOT TASK-204
→ PROCESS-A
→ WORKER-B
and:
ROOT TASK-204
→ PROCESS-C
→ ACCELERATOR-QUEUE-D.
Commands submitted by these descendants contribute to the applicable
root budget.
7.6.42. C-76.36 - Delegation Does Not Reset Exposure
Creating a new descendant execution context does not automatically
create additional effectbudget capacity.
The delegated context either:
(a) consumes the shared root budget directly; or (b) receives a
bounded sub-budget deducted from an ancestor's available capacity.
7.6.43. C-76.37 - Shared Root-Budget Model
In a shared-budget implementation:
All governed descendant commands use the same protected accounting
entry.
For example:
TaskID = TASK-204.
BudgetClass = NETWORK_TX_BYTES.
The budget table stores one shared reservation and completed-effect
state.
Das Expires 25 April 2027 [Page 353]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.44. C-76.38 - Sub-Budget Allocation Model
A trusted controller may allocate:
Root Budget = 1,000 units.
Worker A Sub-Budget = 300.
Worker B Sub-Budget = 200.
Unallocated Root Headroom = 500.
The allocation must prevent a sub-budget from being spent
independently while remaining available for unrestricted root-level
admission.
Unused sub-budget capacity may be returned only under the required
reconciliation and revocation conditions.
7.6.45. C-76.39 - Delegation Identity Substitution
A subordinate worker may attempt to submit a command using a
different TaskID.
The admission controller verifies that the submission context is
authorized for the claimed task.
A command carrying an unsupported task identity is rejected.
7.6.46. PART VI - EFFECT-QUANTITY ESTIMATION
7.6.47. C-76.40 - Command Effect Quantity
Each command receives a bounded exposure quantity q.
For example:
Network transmit command: up to 8,192 bytes.
Storage write command: up to 16 blocks.
DMA command: up to 4,096 destination bytes.
The quantity is expressed in the selected effect unit.
Das Expires 25 April 2027 [Page 354]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.48. C-76.41 - Precise Versus Conservative Bounds
A command may have a precisely known maximum effect.
Alternatively, its exact effect may depend on runtime conditions.
The estimator may reserve a conservative upper bound.
For example:
A descriptor permits a maximum of 64 KiB transfer.
The actual transfer may be smaller.
The controller reserves 64 KiB unless the hardware admission path can
enforce a lower bound.
7.6.49. C-76.42 - Unbounded Command
Some commands may repeat without an established maximum effect
quantity.
If no bounded exposure can be established, the controller may:
1. Reject the command. 2. Split it into bounded subcommands. 3.
Apply a hardware effect meter that gates further execution. 4.
Require additional reservation. 5. Use another verifiably bounded
execution arrangement.
It must not reserve an arbitrarily small estimate while permitting
unbounded effectuation.
7.6.50. C-76.43 - Scatter-Gather Descriptors
A DMA or network command may contain multiple scatter-gather
segments.
The estimator calculates a bound over the segments.
For example:
Segment 1 = 4,096 bytes.
Segment 2 = 2,048 bytes.
Segment 3 = 1,024 bytes.
Total bounded payload = 7,168 bytes.
Das Expires 25 April 2027 [Page 355]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The implementation may account separately for protocol overhead or
physical transmitted bytes depending upon the selected effect
definition.
7.6.51. C-76.44 - Device-Generated Expansion
A hardware engine may expand a compact command into several lower-
level operations.
The estimator must consider the maximum resulting effect quantity.
For example:
One accelerator command may generate multiple DMA writes.
The budget applies to the aggregate covered effect, not merely to the
number of original host descriptors.
7.6.52. C-76.45 - Variable Effect Cardinality
A command may contain a loop or repetition parameter.
The estimator may calculate:
MaximumEffect = MaxIterations × MaximumEffectPerIteration,
subject to checked arithmetic and valid execution bounds.
Overflow, undefined iteration limits, or unsupported arithmetic
causes restriction rather than under-reservation.
7.6.53. C-76.46 - Effect Boundary Definition
The effect class determines when quantity is charged as completed.
Examples:
NETWORK_TX_BYTES: bytes accepted through the defined protected
transmit boundary.
DMA_WRITE_BYTES: bytes confirmed written to the target memory domain.
STORAGE_WRITE_BLOCKS: blocks satisfying the selected storage-
controller completion semantics.
ACCELERATOR_OUTPUT_BYTES: bytes confirmed committed to the designated
output domain.
Das Expires 25 April 2027 [Page 356]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The implementation must not enforcement point remote delivery or
persistence stronger than the underlying completion evidence
establishes.
7.6.54. PART VII - HARDWARE-PROTECTED EFFECT-ACCOUNTING TABLE
7.6.55. C-76.47 - Table Schema
A representative protected entry comprises:
BudgetEntryID.
RootTaskID.
EffectClass.
BudgetLimit.
ReservedOutstanding.
CompletedEffects.
AuthorityGeneration.
AccountingGeneration.
ActiveQueueReferences.
RecoveryState.
7.6.56. C-76.48 - Example Table
7.6.57. Task Effect class Limit Reserved Completed Remaining
| TASK-A Network KiB | 1,024 | 256 | 512 | 256 |
| ------------------ | ----- | --- | ----- | --- |
| TASK-A DMA KiB | 512 | 64 | 128 | 320 |
| TASK-B Network KiB | 2,048 | 512 | 1,024 | 512 |
The quantities are illustrative.
Remaining is calculated as:
Limit - Reserved - Completed.
Das Expires 25 April 2027 [Page 357]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.58. C-76.49 - Per-Command Reservation Record
A representative record comprises:
CommandID = CMD-7601.
RootTaskID = TASK-204.
EffectClass = NETWORK_TX_BYTES.
InitialReservation = 8,192.
CompletedQuantity = 0.
RemainingReservation = 8,192.
QueueID = TXQ-3.
AdmissionGeneration = 301.
Status = ADMITTED.
7.6.59. C-76.50 - Protected Counter Update
The controller updates reserved and completed quantities under an
atomic or otherwise appropriately serialized operation.
Host-controlled counter writes are not accepted as authoritative.
7.6.60. C-76.51 - Budget Provisioning
A trusted management authority establishes:
AuthorizedEffectClass.
BudgetLimit.
TaskIdentity.
ExpirationOrAccountingInterval.
DelegationRules.
The table may have one or more budget generations.
Das Expires 25 April 2027 [Page 358]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.61. C-76.52 - Budget Epoch
A Budget Epoch defines the accounting period or authority generation
for a task.
Commands remain associated with the epoch under which they were
admitted.
The controller does not permit an old command to reuse capacity from
a newly restored or improperly reset epoch.
7.6.62. C-76.53 - Budget Increase
An authorized controller may increase a budget limit.
The increase requires a protected configuration transition.
The AI workload cannot obtain an increase merely by creating another
queue or resetting a process.
7.6.63. C-76.54 - Budget Reduction
An authorized controller may reduce an effect-budget limit.
If existing completed and reserved quantities exceed the new limit,
the controller restricts new admissions.
The treatment of outstanding commands is governed by the selected
revocation or cancellation policy.
A budget reduction does not retroactively undo completed effects.
7.6.64. PART VIII - ATOMIC ADMISSION
7.6.65. C-76.55 - Reservation Before Queue Visibility
A command may be staged in host memory.
The controller obtains or reconstructs its effect descriptor and
quantity.
It atomically reserves capacity.
Only afterward may the command become visible to the executing
hardware queue.
Das Expires 25 April 2027 [Page 359]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.66. C-76.56 - Admission Transaction
A representative admission operation performs:
1. Authenticate task context. 2. Validate effect class. 3.
Determine effect bound. 4. Read protected budget. 5. Check
headroom. 6. Atomically reserve effect capacity. 7. Create command
reservation record. 8. Publish the command to the effect-capable
queue.
The reservation and queue publication order must prevent execution
before the reservation becomes authoritative.
7.6.67. C-76.57 - Admission Failure
If insufficient capacity exists:
CommandStatus = DENIED.
No reservation is committed.
The command is not admitted to the governed effect-capable queue.
7.6.68. C-76.58 - Atomic Compare-and-Update
The reservation mechanism may use:
(a) device-local compare-and-swap; (b) protected atomic fetch-and-add
with validation; (c) a serialized admission processor; (d) a
transaction-capable protected controller; (e) a lock-based protected
table update; (f) another equivalent atomic operation.
The implementation must prevent concurrent over-admission.
7.6.69. C-76.59 - Reservation Publication Barrier
A reservation may commit before the device receives the command.
If queue publication fails, the controller must reconcile the
reservation.
It may release the capacity only after establishing that the command
did not become executable through the governed queue or any relevant
duplicate path.
Das Expires 25 April 2027 [Page 360]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.70. C-76.60 - Duplicate Submission Identity
A host may submit the same command several times.
The controller distinguishes:
1. Duplicate representation of one command. 2. A legitimate retry.
3. Multiple independently executable commands.
A repeated CommandID does not automatically authorize new
effectuation using the old reservation.
7.6.71. PART IX - COMPLETION ACCOUNTING
7.6.72. C-76.61 - Full Completion
A command reserved q units.
The hardware confirms that q units reached the defined effect
boundary.
The controller updates:
ReservedOutstanding := ReservedOutstanding - q.
CompletedEffects := CompletedEffects + q.
The total charged quantity remains unchanged.
7.6.73. C-76.62 - Partial Completion
A command reserved q units.
The hardware confirms p units effected.
Where 0 ≤ p ≤ q:
ReservedOutstanding := ReservedOutstanding - p.
CompletedEffects := CompletedEffects + p.
The remaining reservation equals:
q - p.
No budget headroom is created merely by transferring a charged
quantity from reserved to completed.
Das Expires 25 April 2027 [Page 361]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.74. C-76.63 - Example Partial Transfer
Initial command reservation:
100 KiB.
Actual confirmed transfer:
40 KiB.
After reconciliation:
Completed = 40 KiB.
Outstanding reservation = 60 KiB.
The total charged quantity remains 100 KiB.
7.6.75. C-76.64 - Verified Cancellation of Remaining Portion
Suppose the controller proves that the remaining 60 KiB can no longer
be transmitted.
It may then release 60 KiB of outstanding reservation.
Final command accounting:
Completed = 40 KiB.
Outstanding = 0.
Released unused capacity = 60 KiB.
The completed 40 KiB remains charged.
7.6.76. C-76.65 - Partial Cancellation Without Complete Evidence
Suppose a device reports cancellation but cannot establish how many
bytes already crossed the effect boundary.
| The controller may retain the uncertain quantity as charged. It does not automatically release the entire reservation. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.66 - Completion Greater Than Reservation A hardware command must not be allowed to produce a governed effect quantity exceeding its reservation without corresponding authorized additional capacity. An implementation may: 1. Enforce descriptor length bounds. 2. Split commands into separately reserved segments. 3. Stop effectuation before the bound is exceeded. 4. Obtain additional reservation before proceeding. A completion report exceeding the reserved quantity indicates a serious invariant violation or measurement failure and must not merely decrement counters into an invalid state. |
| C-76.67 - Failed Command A command may fail before effectuation. If the controller establishes that no portion can subsequently execute, the entire reservation may be released. If the command failed after partial effectuation, only the verified non-effected remainder may be released. |
Das Expires 25 April 2027 [Page 362]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.77. C-76.68 - Device Completion Semantics
A completion acknowledgment may refer to:
(a) descriptor consumption; (b) DMA completion; (c) internal queue
retirement; (d) remote acknowledgment; (e) persistent storage commit.
The controller must use the evidence appropriate to the defined
effect class.
Descriptor retirement alone does not necessarily prove that a remote
service received or durably stored a transmitted payload.
7.6.78. PART X - COMMAND CANCELLATION
7.6.79. C-76.69 - Cancellation Request State
A command may enter:
CANCEL_REQUESTED.
This state alone does not release its reservation.
7.6.80. C-76.70 - Execution Fence
A hardware cancellation may require an execution fence that prevents
the remaining command portion from reaching the effect boundary.
For example:
1. Stop queue dispatch. 2. Revoke descriptor ownership. 3. Wait
for in-flight DMA completion. 4. Drain applicable pipeline stages.
5. Determine completed quantity.
6. Confirm remaining work is non-executable.
The actual fence procedure depends upon the device.
7.6.81. C-76.71 - Queue Ownership
A command may have moved from one queue to another.
The controller must identify all relevant execution locations before
declaring the command canceled.
Canceling only the original queue entry is insufficient if an
alternate execution path remains active.
Das Expires 25 April 2027 [Page 363]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.82. C-76.72 - Late Completion
A completion event may arrive after a cancellation request.
| |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The controller reconciles it against the existing reservation. The completed portion remains charged. |
| C-76.73 - Cancellation Race A cancellation request and completion event may occur concurrently. The protected command state machine serializes their accounting effects. The same quantity is not simultaneously released and charged through inconsistent transactions. |
| C-76.74 - No Double Refund A command may receive duplicate cancellation acknowledgments. The controller uses the protected CommandID and accounting generation to prevent repeated release of the same reserved capacity. |
7.6.83. PART XI - NETWORK, SMARTNIC, DPU, AND DMA IMPLEMENTATIONS
7.6.84. C-76.75 - Programmable NIC Admission
A programmable NIC may intercept transmit descriptors before hardware
transmission.
The NIC associates each descriptor with a protected task context.
It reserves the applicable transmission budget before making the
descriptor eligible for transmission.
7.6.85. C-76.76 - SmartNIC Implementation
A SmartNIC may maintain:
Task budget entries.
Per-queue command identities.
Reservation counters.
Completion counters.
Queue-generation state.
Protected cancellation status.
Its embedded control processor may coordinate accounting across
several hardware transmit queues.
7.6.86. C-76.77 - DPU Implementation
A DPU may host the admission controller independently of the AI
agent's CPU process.
The DPU receives command submissions from one or more host contexts.
Das Expires 25 April 2027 [Page 364]
Internet-Draft Kernel-Hardware Execution Finality October 2026
It enforces a shared originating task budget before allowing the
relevant network or storage operation.
7.6.87. C-76.78 - DMA Controller Implementation
A DMA controller may regulate memory-copy or peripheral transfer
descriptors.
The estimator determines a bounded quantity based upon destination
range, transfer length, repetition parameters, and effect class.
The command is admitted only after the corresponding reservation.
| C-76.79 - IOMMU-Associated Protection An IOMMU may provide address translation and isolation. However, ordinary IOMMU address translation does not inherently implement effect-budget accounting. A claimed IOMMU-associated embodiment therefore includes a separate admission or command-metering function that actually maintains and enforces the protected budget state. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.80 - Accelerator Queue Implementation An accelerator command may produce persistent resource changes, DMA transfers, or external device operations. The command admission controller calculates a bounded effect quantity. Where the effect size cannot be established before execution, the accelerator may require segmented or continuously metered execution under protected reservations. |
| C-76.81 - SR-IOV and Virtual Functions Several virtual functions may submit commands to a shared physical NIC. The controller associates their queues with the same originating task when appropriate. The shared budget is enforced across the relevant functions. Assigning a new virtual function must not reset the root task's accumulated exposure. |
7.6.88. C-76.82 - Host Process Aggregation
Two host processes may submit commands through separate rings.
The protected task association maps both to:
RootTaskID = TASK-204.
Both consume the same budget entry.
This implements a principal feature of enforcement point(s) 77.
7.6.89. PART XII - HARDWARE RESET AND RECOVERY
7.6.90. C-76.83 - Persisted Budget State
A controller may maintain durable or recoverable records of:
1. Current budget epoch. 2. Completed quantity. 3. Outstanding
reserved quantity. 4. Active command identities. 5. Queue
associations. 6. Reservation generations. 7. Delegation context. 8.
Recovery status.
The persistence mechanism must support the selected reset and failure
guarantees.
7.6.91. C-76.84 - Host Restart
Following a host restart, previously admitted device commands may
remain active.
Das Expires 25 April 2027 [Page 365]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The controller does not rebuild its budget solely from the restarted
host's empty software queue state.
It reconciles against device-resident command and effect state.
7.6.92. C-76.85 - Device Controller Reset
A device reset may destroy volatile queue state.
The recovery mechanism determines whether:
(a) all commands were definitively aborted; (b) some effects
completed; (c) in-flight effects remain uncertain; (d) another engine
retained executable work; or (e) a standby controller may complete
the commands.
Budget capacity is not released without the required evidence.
7.6.93. C-76.86 - VM Snapshot Restoration
A VM may restore an old software descriptor queue.
The protected accounting table remains associated with the current
budget generation.
Replayed descriptors carrying obsolete submission generations are
rejected or reconciled.
The restored VM cannot obtain an earlier unused budget balance merely
by reverting its own memory.
7.6.94. C-76.87 - VM Migration
A task may migrate to another host or device.
The system transfers or reestablishes:
RootTaskID.
BudgetGeneration.
CompletedEffects.
OutstandingReservations.
LiveCommandReferences.
DelegationState.
Das Expires 25 April 2027 [Page 366]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The migration procedure must prevent simultaneous unrestricted
command execution under the same full budget on both source and
destination devices.
7.6.95. C-76.88 - Source Device Fencing
Before destination activation under a transferred shared budget, the
system may fence the source execution domain.
| It verifies that relevant commands cannot continue independently without accounting. Where source commands remain executable, their reservations stay charged. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.89 - Queue Failover A command may be copied to a standby queue. The controller records whether the copy represents: (a) the same logical command with only one permitted execution; or (b) an independently executable duplicate. A failover mechanism that permits both copies to execute must reserve sufficient possible effect quantity or enforce single-execution fencing. |
| C-76.90 - Recovery Epoch A Recovery Epoch identifies the current controller state after restart or failover. Previously released reservations cannot be reused to authorize commands still executable under an older epoch. A monotonic or otherwise rollback-resistant generation mechanism may be employed. |
7.6.96. C-76.91 - Uncertain Outstanding Commands
When authoritative queue state is unavailable, the controller may
retain the associated reservation.
The command remains classified:
INDETERMINATE.
It cannot be treated as canceled merely because the host no longer
recognizes it.
7.6.97. C-76.92 - Recovery Accounting Reconciliation
A representative reconciliation compares:
PersistedBudgetState.
CurrentHardwareQueueState.
CompletionRecords.
KnownCancellationFences.
DelegatedQueueReferences.
FailoverExecutionState.
The controller constructs a conservative current accounting
representation before resuming admissions.
Das Expires 25 April 2027 [Page 367]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.98. PART XIII - COMPLETE 40-STEP WORKFLOW
7.6.99. C-76.93 - Principal Execution Workflow
7.6.100. Step C76-01 - Task identity establishment
Establish an authenticated root task context.
7.6.101. Step C76-02 - Budget-policy retrieval
Obtain the task's authorized effect classes and limits.
7.6.102. Step C76-03 - Hardware budget provisioning
Initialize or locate protected accounting entries.
7.6.103. Step C76-04 - Execution-context association
Bind the host process, worker, or queue to the root task.
7.6.104. Step C76-05 - Delegation verification
Validate applicable descendant task associations.
7.6.105. Step C76-06 - Command generation
The AI workload or delegated component produces a resource-operation
command.
7.6.106. Step C76-07 - Command staging
Hold the command outside the effect-capable queue.
7.6.107. Step C76-08 - Submission context authentication
Verify the originating hardware submission context.
7.6.108. Step C76-09 - Root budget identification
Resolve the applicable shared or delegated budget.
7.6.109. Step C76-10 - Effect-class classification
Identify the command's governed resource-effect class.
Das Expires 25 April 2027 [Page 368]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.110. Step C76-11 - Descriptor validation
Validate lengths, pointers, operation type, and other relevant
fields.
7.6.111. Step C76-12 - Effect-bound estimation
Calculate a bounded possible effect quantity.
7.6.112. Step C76-13 - Bound adequacy verification
Confirm that the controller can enforce the declared maximum.
7.6.113. Step C76-14 - Protected budget read
Obtain reserved, completed, and authorized quantities.
7.6.114. Step C76-15 - Capacity evaluation
Determine whether the new command fits within available headroom.
7.6.115. Step C76-16 - Atomic reservation
Increase the outstanding reserved quantity under protected
serialization.
7.6.116. Step C76-17 - Reservation record commitment
Bind the reservation to the command and accounting generation.
7.6.117. Step C76-18 - Queue publication
Make the reserved command eligible for hardware execution.
7.6.118. Step C76-19 - Admission outcome recording
Record admitted or rejected status.
7.6.119. Step C76-20 - Hardware execution
The command executes within the governed resource interface.
7.6.120. Step C76-21 - Effect-bound enforcement
Prevent execution beyond the reserved exposure.
Das Expires 25 April 2027 [Page 369]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.121. Step C76-22 - Completion observation
Obtain authoritative progress or completion information.
7.6.122. Step C76-23 - Partial effect quantification
Determine the confirmed completed quantity.
7.6.123. Step C76-24 - Protected reconciliation
Transfer completed quantity from reserved to completed accounting.
7.6.124. Step C76-25 - Remaining reservation retention
Retain reserved capacity for work that may still execute.
7.6.125. Step C76-26 - Cancellation request handling
Accept cancellation requests without premature release.
7.6.126. Step C76-27 - Execution fencing
Establish whether remaining command work is non-executable.
7.6.127. Step C76-28 - Verified cancellation accounting
Release only the verifiably canceled remainder.
7.6.128. Step C76-29 - Duplicate-event control
Prevent repeated accounting for completion or cancellation reports.
7.6.129. Step C76-30 - Delegated-work aggregation
Charge descendant effects against the applicable root budget.
7.6.130. Step C76-31 - Host restart detection
Identify restarted host or execution context.
7.6.131. Step C76-32 - Controller reset detection
Identify hardware accounting or queue continuity events.
7.6.132. Step C76-33 - Recovery epoch establishment
Create or verify the protected recovery generation.
Das Expires 25 April 2027 [Page 370]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.133. Step C76-34 - Queue inventory reconstruction
Identify outstanding commands in all relevant execution paths.
7.6.134. Step C76-35 - Persisted state reconciliation
Compare queued commands and completed effects with protected budget
state.
7.6.135. Step C76-36 - Alternate-path fencing
Prevent duplicate execution under stale or transferred reservations.
7.6.136. Step C76-37 - Recovery accounting commitment
Record the reconciled protected budget.
7.6.137. Step C76-38 - Current invariant verification
Confirm completed plus reserved exposure does not exceed the
authorized limit.
7.6.138. Step C76-39 - Admission resumption
Resume new queue admissions when the required state is consistent.
7.6.139. Step C76-40 - Audit and continuity recording
Retain accounting, delegation, execution, and recovery references.
7.6.140. PART XIV - REFERENCE IMPLEMENTATION ALGORITHMS
7.6.141. C-76.94 - Algorithm A: Protected Task-Context Resolution
function ResolveProtectedTaskContext(submission):
queue_context = DeviceQueueRegistry.get(
submission.queue_id
)
if queue_context is unavailable:
return DENIED
authenticated_owner = VerifyQueueOwner(
queue_context,
submission
)
Das Expires 25 April 2027 [Page 371]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if authenticated_owner is invalid:
return DENIED
task_binding = ProtectedTaskRegistry.lookup(
authenticated_owner,
queue_context
)
if not VerifyCurrentTaskBinding(task_binding):
return DENIED
root_task = ResolveOriginatingTask(
task_binding
)
return root_task
The controller does not rely solely upon an untrusted host-supplied
TaskID.
7.6.142. C-76.95 - Algorithm B: Effect-Quantity Estimation
function EstimateBoundedEffect(command, effect_class):
if not VerifyCommandDescriptor(command):
return INVALID
if effect_class == NETWORK_TX_BYTES:
bound = ComputeMaximumTransmittableBytes(command)
else if effect_class == DMA_WRITE_BYTES:
bound = ComputeMaximumDMAWriteLength(command)
else if effect_class == STORAGE_WRITE_BLOCKS:
bound = ComputeMaximumStorageBlockWrites(command)
else if effect_class == ACCELERATOR_OUTPUT_BYTES:
bound = ComputeMaximumAcceleratorOutput(command)
else:
bound = ResolveRegisteredEffectBound(
command,
effect_class
)
if bound is UNKNOWN or UNBOUNDED:
return REQUIRES_BOUNDED_SEGMENTATION
if not CheckedNonnegativeInteger(bound):
return INVALID
if not HardwareCanEnforceEffectBound(command, bound):
return INVALID
Das Expires 25 April 2027 [Page 372]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return bound
An estimator must not reserve a value smaller than the supported
maximum effect quantity.
7.6.143. C-76.96 - Algorithm C: Atomic Hardware Queue Admission
function AdmitHardwareCommand(command, submission):
task = ResolveProtectedTaskContext(submission)
if task is invalid:
return DENIED
effect_class = ClassifyResourceEffect(command)
quantity = EstimateBoundedEffect(
command,
effect_class
)
if quantity is invalid:
return DENIED
entry = ProtectedBudgetTable.lookup(
task.root_id,
effect_class
)
begin protected_atomic_update(entry)
if entry.status != ACTIVE:
abort
return DENIED
if entry.completed +
entry.reserved +
quantity > entry.limit:
abort
return BUDGET_EXHAUSTED
command_id = AllocateProtectedCommandID()
Das Expires 25 April 2027 [Page 373]
Internet-Draft Kernel-Hardware Execution Finality October 2026
entry.reserved += quantity
ReservationTable.insert({
command_id: command_id,
root_task: task.root_id,
effect_class: effect_class,
initial_quantity: quantity,
remaining_quantity: quantity,
completed_quantity: 0,
admission_generation: entry.generation,
status: RESERVED_NOT_PUBLISHED
})
commit protected_atomic_update
if not PublishToProtectedExecutionQueue(
command_id,
command
):
ReconcileFailedPublication(command_id)
return ADMISSION_INCOMPLETE
return ADMITTED
Publication occurs only after protected reservation.
7.6.144. C-76.97 - Algorithm D: Protected Budget Invariant Check
function VerifyBudgetInvariant(entry):
if entry.limit < 0:
return INVALID
if entry.completed < 0:
return INVALID
if entry.reserved < 0:
return INVALID
if ArithmeticOverflowDetected(entry):
return INVALID
if entry.completed + entry.reserved > entry.limit:
return VIOLATION
return VALID
Checked arithmetic is necessary where counters have bounded
representations.
7.6.145. C-76.98 - Algorithm E: Partial Completion Reconciliation
Das Expires 25 April 2027 [Page 374]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function ReconcilePartialCompletion(
command_id,
hardware_completion
):
if not VerifyHardwareCompletionEvidence(
hardware_completion
):
return DENIED
record = ReservationTable.get(command_id)
begin protected_atomic_update(
record,
ProtectedBudgetTable[record.root_task,
record.effect_class]
)
newly_completed = DetermineNewlyConfirmedQuantity(
record,
hardware_completion
)
if newly_completed < 0:
abort
return INVALID
if newly_completed > record.remaining_quantity:
abort
return ACCOUNTING_VIOLATION
record.completed_quantity += newly_completed
record.remaining_quantity -= newly_completed
budget.completed += newly_completed
budget.reserved -= newly_completed
AdvanceAccountingGeneration(record, budget)
commit protected_atomic_update
return RECONCILED
The quantity transferred from reserved to completed remains charged
against the budget.
7.6.146. C-76.99 - Algorithm F: Verified Cancellation
function CancelHardwareCommand(command_id):
record = ReservationTable.get(command_id)
if record is unavailable:
Das Expires 25 April 2027 [Page 375]
Internet-Draft Kernel-Hardware Execution Finality October 2026
return DENIED
MarkCancelRequested(record)
fence = RequestHardwareExecutionFence(command_id)
if not VerifyFenceCompletion(fence):
return CANCELLATION_UNCONFIRMED
progress = QueryAuthoritativeEffectProgress(
command_id
)
if progress is UNKNOWN:
return CANCELLATION_UNCONFIRMED
ReconcilePartialCompletion(
command_id,
progress
)
remaining = ReservationTable.get(
command_id
).remaining_quantity
if not VerifyCommandCannotCompleteElsewhere(
command_id
):
return CANCELLATION_UNCONFIRMED
begin protected_atomic_update
budget.reserved -= remaining
record.remaining_quantity = 0
record.status = CANCELED_VERIFIED
MarkReservationReleasedExactlyOnce(
command_id
)
commit protected_atomic_update
return CANCELED_VERIFIED
A cancellation request does not itself release the reservation.
7.6.147. C-76.100 - Algorithm G: Shared Delegated Budget
Das Expires 25 April 2027 [Page 376]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function AdmitDelegatedCommand(
descendant_context,
command
):
delegation = ProtectedDelegationRegistry.get(
descendant_context
)
if not VerifyDelegationGeneration(delegation):
return DENIED
root_task = delegation.root_task_id
if not VerifyCommandWithinDelegatedScope(
command,
delegation
):
return DENIED
return AdmitHardwareCommand(
command,
BuildAuthenticatedSubmissionContext(
descendant_context,
root_task
)
)
The delegated worker does not receive a new unrestricted root budget.
7.6.148. C-76.101 - Algorithm H: Cross-Queue Atomic Coordination
Das Expires 25 April 2027 [Page 377]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function ReserveAcrossSharedQueues(
root_task,
effect_class,
quantity,
queue_id
):
entry = ProtectedBudgetTable.lookup(
root_task,
effect_class
)
lock(entry)
try:
if entry.completed +
entry.reserved +
quantity > entry.limit:
return DENIED
entry.reserved += quantity
reservation_id = CommitQueueReservation({
task: root_task,
queue: queue_id,
quantity: quantity,
generation: entry.generation
})
return reservation_id
finally:
unlock(entry)
All relevant queues use the same protected accounting serialization
point or an equivalent coordinated mechanism.
C-76.102 - Algorithm I: Completion and Cancellation Race Resolution
function ApplyCommandStateEvent(command_id, event):
record = ReservationTable.lock(command_id)
if EventAlreadyApplied(record, event.id):
unlock(record)
return DUPLICATE
if record.status == CANCELED_VERIFIED:
if event reports new effect:
RaiseProtectedConsistencyFailure()
unlock(record)
return VIOLATION
if event.type == EFFECT_PROGRESS:
result = ReconcileVerifiedProgress(record, event)
Das Expires 25 April 2027 [Page 378]
Internet-Draft Kernel-Hardware Execution Finality October 2026
else if event.type == CANCELLATION_ACK:
result = EvaluateAuthoritativeCancellation(
record,
event
)
else:
result = APPLY_SUPPORTED_STATE_EVENT
MarkEventApplied(record, event.id)
unlock(record)
return result
Events are applied exactly once to the protected accounting state.
7.6.149. C-76.103 - Algorithm J: Host Restart Recovery
function RecoverAfterHostRestart(task_id):
SuspendNewAdmissions(task_id)
persisted = ProtectedBudgetStore.readCurrent(task_id)
device_queues = EnumerateAuthoritativeDeviceQueues(
task_id
)
reconciled = ReconcileCommandReservations(
persisted,
device_queues,
HardwareCompletionHistory()
)
if reconciled is INCOMPLETE:
KeepAffectedReservationsCharged(task_id)
return RECOVERY_RESTRICTED
if not VerifyBudgetInvariant(reconciled):
return RECOVERY_FAILED
CommitRecoveredBudgetGeneration(reconciled)
ResumeAdmissions(task_id)
return RECOVERED
The restarted host's software queue state is not treated as the sole
source of authoritative outstanding-command information.
7.6.150. C-76.104 - Algorithm K: Controller Reset Recovery
Das Expires 25 April 2027 [Page 379]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function RecoverAfterControllerReset(controller_id):
BlockEffectCapableQueueAdmissions(controller_id)
generation = AdvanceRecoveryEpoch(controller_id)
persisted = RecoverProtectedAccountingState(
controller_id
)
outstanding = DiscoverSurvivingExecutableCommands(
controller_id
)
remote = QueryApplicableFailoverExecutionPaths(
controller_id
)
reconciled = ConservativeMerge(
persisted,
outstanding,
remote
)
if not CanEstablishSafeCommandContinuity(reconciled):
RetainConservativeReservations(reconciled)
return RESTRICTED_RECOVERY
CommitRecoveredState(
reconciled,
generation
)
return READY_FOR_VERIFIED_ADMISSION
A device reset does not itself prove that all prior effects are
canceled.
7.6.151. C-76.105 - Algorithm L: VM Migration with Budget Fencing
function MigrateTaskBudget(
task_id,
source_controller,
target_controller
):
SuspendNewAdmissions(task_id)
source_state = CaptureProtectedBudgetState(
source_controller,
task_id
)
Das Expires 25 April 2027 [Page 380]
Internet-Draft Kernel-Hardware Execution Finality October 2026
fence = FenceSourceTaskQueues(
source_controller,
task_id
)
if not VerifySourceFenceOrRetainReservations(fence):
return MIGRATION_RESTRICTED
new_epoch = AllocateProtectedMigrationGeneration()
transferred = TransferAuthenticatedBudgetState({
task_id: task_id,
completed: source_state.completed,
reserved: source_state.reserved,
live_commands: source_state.live_commands,
generation: new_epoch
})
if not VerifyTransferredAccounting(
transferred,
target_controller
):
return MIGRATION_FAILED
ActivateTargetUnderTransferredBudget(
target_controller,
transferred
)
return MIGRATED
The migration must not create independently spendable copies of the
same budget.
7.6.152. C-76.106 - Algorithm M: Queue Failover Duplicate Prevention
Das Expires 25 April 2027 [Page 381]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function AdmitFailoverCommand(
original_command_id,
standby_queue
):
original = ReservationTable.get(
original_command_id
)
if original is unavailable:
return DENIED
if not VerifyAuthorizedFailoverTransition(
original,
standby_queue
):
return DENIED
if not VerifyOriginalExecutionFenced(
original_command_id
):
if not CanReserveBothPossibleExecutions(
original,
standby_queue
):
return DENIED
BindFailoverQueueToExistingOrExpandedReservation(
original,
standby_queue
)
return FAILOVER_ADMITTED
One reservation may authorize failover only where the device
guarantees that the original and standby copies cannot independently
produce more effect than the reserved amount.
7.6.153. C-76.107 - Algorithm N: Lost Completion Acknowledgment
function ReconcileUnknownCommandOutcome(command_id):
record = ReservationTable.get(command_id)
observed = QueryAuthoritativeDeviceEffectState(
command_id
)
if observed == CONFIRMED_COMPLETED:
return ReconcileVerifiedCompletion(record)
if observed == CONFIRMED_NOT_EFFECTUABLE:
return ReleaseVerifiedUnusedReservation(record)
Das Expires 25 April 2027 [Page 382]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if observed == PARTIALLY_COMPLETED:
return ReconcilePartialCompletion(
record,
observed
)
MarkCommandIndeterminate(record)
RetainUnresolvedEffectQuantity(record)
return RECONCILIATION_REQUIRED
An unknown completion outcome does not create additional budget
headroom.
7.6.154. C-76.108 - Algorithm O: Protected Budget Integrity Audit
function AuditTaskEffectBudget(task_id):
budget_entries = ProtectedBudgetTable.getAll(task_id)
for each entry in budget_entries:
command_records = ReservationTable.query({
root_task: task_id,
effect_class: entry.effect_class
})
expected_reserved = SumRemainingReservations(
command_records
)
expected_completed = SumCompletedEffectCharges(
command_records,
AuthorizedBaselineAccounting(entry)
)
if expected_reserved != entry.reserved:
return ACCOUNTING_INCONSISTENCY
if expected_completed != entry.completed:
return ACCOUNTING_INCONSISTENCY
if not VerifyBudgetInvariant(entry):
return BUDGET_VIOLATION
return ACCOUNTING_CONSISTENT
The audit must handle durable history retention and accounted
commands that have been archived or summarized.
7.6.155. PART XV - WORKED TECHNICAL EXAMPLES
Das Expires 25 April 2027 [Page 383]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.156. C-76.109 - Example A: SmartNIC Network Byte Budget
The following is a hypothetical implementation example.
An AI agent receives a network egress budget of 1 MiB.
The agent has already transmitted 512 KiB.
Another 256 KiB is reserved for queued commands.
The remaining budget is 256 KiB.
A new 128 KiB command may be admitted.
A new 512 KiB command must be rejected or segmented under an
appropriate bounded admission policy.
The protected counters are updated before the accepted command
becomes eligible for transmission.
7.6.157. C-76.110 - Example B: Partial Network Transmission
A command reserves 100 KiB.
The NIC confirms transmission of 40 KiB.
Cancellation is requested.
The controller reconciles:
Completed = 40 KiB.
Remaining reserved = 60 KiB.
After authoritative fencing proves that the remaining 60 KiB cannot
transmit, the controller releases only the 60 KiB.
The completed 40 KiB remains charged.
7.6.158. C-76.111 - Example C: Two Processes Sharing One Budget
An AI agent creates two worker processes.
Each submits network commands through a different transmit ring.
Both are associated with RootTask TASK-204.
The protected table maintains one shared network-effect budget.
Das Expires 25 April 2027 [Page 384]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Concurrent reservations are atomically serialized.
The workers cannot independently consume the same remaining capacity.
7.6.159. C-76.112 - Example D: NIC Virtual Functions
Two SR-IOV virtual functions are assigned to workloads delegated from
the same AI task.
Each virtual function has a distinct submission context.
The hardware admission controller maps both to the root task.
Their queued and completed transmissions contribute to the shared
effect-budget entry.
Creating another virtual function does not reset the task's budget.
7.6.160. C-76.113 - Example E: DMA Write Budget
An agent-controlled accelerator submits DMA writes to a designated
output buffer.
The task's authorized DMA write budget is 256 KiB.
Before admitting a DMA command, the controller determines its maximum
target-write length.
The bounded quantity is reserved.
A command exceeding remaining capacity is rejected or divided into
smaller independently reserved segments.
C-76.114 - Example F: Accelerator Command Expansion
A host submits one accelerator command.
The accelerator may generate four DMA output transfers.
The command estimator determines that the total possible output is
128 KiB.
The controller reserves the aggregate 128 KiB before accepting the
command into the effectcapable queue.
It does not reserve only one command count when the protected budget
is defined in output bytes.
Das Expires 25 April 2027 [Page 385]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.161. C-76.115 - Example G: Storage Partial Write
A storage command reserves sixteen blocks.
The controller confirms that ten blocks reached the specified storage
effect boundary.
The device reports failure before the remaining six blocks complete.
The controller retains ten blocks as completed.
The remaining six blocks may be released only after the device
establishes that they cannot subsequently be written.
The distinction between issued, acknowledged, and durable writes
follows the selected storage effect definition.
7.6.162. C-76.116 - Example H: Cancellation During DMA
7.6.163. Execution
A DMA controller has accepted a descriptor for 64 KiB.
The host requests cancellation after the transfer begins.
The device confirms that 24 KiB was written.
The remaining transfer is fenced.
The controller records 24 KiB as completed and releases only the
verified unused 40 KiB.
A cancellation acknowledgment without the necessary completion
evidence would not justify releasing the entire reservation.
C-76.117 - Example I: Host Restart with Active Device Queue
An agent process queues network descriptors.
The host crashes before all descriptors complete.
The network adapter retains active queue state.
After restart, the controller reconstructs outstanding commands from
device state and protected accounting records.
It does not treat the host's newly empty process memory as evidence
that reserved capacity can be released.
Das Expires 25 April 2027 [Page 386]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.164. C-76.118 - Example J: VM Snapshot Replay
A virtual machine submits a DMA operation under Budget Generation 31.
It is later restored from an older snapshot containing an earlier
software budget view.
The hardware controller retains or reconstructs the current protected
accounting generation.
A replayed descriptor using an obsolete submission generation cannot
independently obtain fresh budget authority.
7.6.165. C-76.119 - Example K: Queue Failover
A storage command is admitted to Queue A.
The command's acknowledgment is lost.
A failover mechanism attempts to submit the same command through
Queue B.
The controller checks whether Queue A can still complete the command.
If it can, the controller either reserves sufficient exposure for
both possible executions or prevents Queue B from executing until
Queue A is authoritatively fenced.
The original reservation is not automatically released or reused.
| C-76.120 - Example L: Controller Reset A device controller resets while several commands are outstanding. Protected accounting state indicates that 400 units remain reserved. The recovery mechanism determines that some commands may have partially completed. The controller retains unresolved charged exposure while reconstructing queue state. New admissions resume only when the applicable invariant is preserved. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.121 - Example M: Delegated Accelerator Workers An AI task delegates computation to three accelerator workers. Each worker submits output-copy commands. All commands use the originating task's shared output budget. The Delegation-Accounting Controller does not issue an independent full budget for each accelerator worker. |
| C-76.122 - Example N: Concurrent Last-Unit Race A task has one permitted operation unit remaining. Two device submission queues receive commands simultaneously. Both attempt to reserve one unit. The protected atomic counter admits only one request. The second is rejected because the first reservation has already consumed the available capacity. |
7.6.166. C-76.123 - Example O: Duplicate Cancellation Acknowledgment
A command reserves 20 KiB.
It is canceled with authoritative proof that no effect occurred.
The controller releases the 20 KiB once.
A duplicate cancellation acknowledgment arrives.
The protected reservation record is already marked released.
The second event does not credit the budget again.
Das Expires 25 April 2027 [Page 387]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.167. C-76.124 - Example P: Unbounded Hardware Command
An accelerator command contains a repetition parameter with no
verified maximum.
The controller cannot establish its worst-case resource effect.
It refuses admission as an unbounded single command.
The host may instead submit bounded segments, each independently
reserved before execution.
7.6.168. PART XVI - FAILURE AND ADVERSARIAL CONDITIONS
7.6.169. C-76.125 - Representative Failure Cases
7.6.170. F1 - Queue Admission Before Reservation
A command becomes effect-capable before accounting commits.
The hardware admission barrier prevents execution until reservation
is authoritative.
7.6.171. F2 - Software-Only Counter
An agent modifies a host-local budget counter.
The protected controller ignores unauthorized host accounting
changes.
7.6.172. F3 - Forged Task Identity
A command enforcement points another task's budget.
Protected submission-context binding rejects the enforcement point.
7.6.173. F4 - Child Process Budget Reset
A descendant process attempts to obtain a new full allowance.
Delegation accounting preserves the originating task limit.
7.6.174. F5 - Alternate Queue Bypass
A workload submits through an ungoverned queue.
The claimed protected effect domain must include the relevant queue
or deny that route.
Das Expires 25 April 2027 [Page 388]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.175. F6 - Concurrent Reservation Race
Two queues simultaneously consume the same apparent headroom.
Atomic admission prevents over-reservation.
7.6.176. F7 - Integer Overflow
The sum of reserved and completed quantities exceeds the counter
range.
Checked arithmetic rejects unsafe updates.
7.6.177. F8 - Negative Accounting
A malformed completion event would make the reserved counter
negative.
Protected invariant checks reject the transition.
7.6.178. F9 - Underestimated Command Effect
The estimator reserves less than the command can produce.
The admission controller requires enforceable bounds or segmented
execution.
7.6.179. F10 - Unbounded Command
A command lacks a finite maximum effect quantity.
It is rejected or divided into bounded units.
7.6.180. F11 - Descriptor Tampering After Admission
The host modifies command length or resource target after
reservation.
The controller uses a protected descriptor snapshot or revalidates
the actual command before effectuation.
7.6.181. F12 - Scatter-Gather Expansion
Multiple descriptor segments exceed the reserved length.
The estimator accounts for the aggregate maximum.
Das Expires 25 April 2027 [Page 389]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.182. F13 - Accelerator-Generated Extra Effects
The accelerator expands one command into additional resource
operations.
The bounded-effect model includes those operations or restricts
expansion.
7.6.183. F14 - Incorrect Unit Conversion
The system confuses bytes with blocks or commands.
Typed effect dimensions prevent incompatible accounting.
7.6.184. F15 - Wrong Completion Boundary
The device reports descriptor retirement but not actual protected
effectuation.
The accounting model specifies and verifies its true effect boundary.
7.6.185. F16 - Premature Cancellation Refund
The host requests cancellation while a command remains executable.
Reserved capacity is retained.
7.6.186. F17 - Partial Completion Ignored
The controller releases a whole reservation after partial
effectuation.
The reconciliation procedure retains the completed portion.
7.6.187. F18 - Duplicate Completion Event
A completion event is delivered twice.
Stable command and event identity prevent double charging.
7.6.188. F19 - Duplicate Cancellation Event
A cancellation event is delivered twice.
The protected record prevents double refund.
Das Expires 25 April 2027 [Page 390]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.189. F20 - Completion-Cancellation Race
Completion and cancellation occur concurrently.
Protected serialization preserves consistent accounting.
7.6.190. F21 - Late Hardware Completion
A completion arrives after cancellation was requested.
The controller charges the confirmed effect.
7.6.191. F22 - Canceled Queue Entry Still Executable Elsewhere
The original entry is removed but another queue holds an executable
copy.
Capacity is retained until alternate paths are fenced.
7.6.192. F23 - Queue Publication Failure
Reservation succeeds but command publication fails.
The controller establishes non-effectuation before releasing
capacity.
7.6.193. F24 - Lost Admission Acknowledgment
The host does not learn whether admission succeeded.
Protected command identity and queue state are queried before retry.
7.6.194. F25 - Lost Completion Acknowledgment
The operation may have effected a resource change.
The corresponding quantity remains charged pending reconciliation.
7.6.195. F26 - Host Restart
Host-local records disappear while the device retains commands.
Protected recovery uses device and durable accounting state.
7.6.196. F27 - Device Reset
Volatile queue state disappears.
Das Expires 25 April 2027 [Page 391]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The controller does not assume all earlier commands were harmless.
7.6.197. F28 - VM Snapshot Rollback
The VM restores an earlier software allowance.
Protected budget generations prevent reuse of stale authority.
7.6.198. F29 - VM Migration Duplication
Source and destination devices can execute the same command.
Migration fencing or sufficient dual-execution reservation is
required.
7.6.199. F30 - Failover Queue Duplicate
A standby queue executes work while the original remains active.
The controller prevents duplicate use of one insufficient
reservation.
7.6.200. F31 - Stale Reservation Reuse
A previously released reservation ID is presented again.
Protected generation and terminal-state checks reject reuse.
7.6.201. F32 - Controller State Rollback
The protected budget table is restored to a stale state.
Recovery continuity checks prevent reactivation under invalid
accounting.
7.6.202. F33 - Delegation Context Substitution
A descendant worker attempts to switch task attribution.
Authenticated delegation mapping prevents the change.
7.6.203. F34 - Cross-Process Budget Fragmentation
Each process has a separate local counter while sharing one intended
task cap.
The controller aggregates against the shared protected root entry.
Das Expires 25 April 2027 [Page 392]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.204. F35 - Device Virtual Function Reassignment
A queue owner changes without correct task reassociation.
The controller requires a valid current mapping.
7.6.205. F36 - Unauthorized Budget Increase
The workload attempts to raise its authorized limit.
Only the trusted configuration authority may modify the budget.
7.6.206. F37 - Revocation During Execution
The authorized task budget is reduced while commands are outstanding.
New admissions are restricted and pending work is handled according
to defined cancellation or completion rules.
7.6.207. F38 - Stale Budget Epoch
A command from an obsolete authority generation is submitted.
The controller rejects or revalidates it.
7.6.208. F39 - Hardware Accounting Memory Corruption
The protected accounting table fails integrity checks.
Affected admissions are suspended pending recovery.
7.6.209. F40 - Controller Firmware Compromise
The trusted hardware admission mechanism is compromised.
The guarantee depends upon the defined controller trust boundary and
cannot be assumed to survive compromise of its own trusted computing
base.
7.6.210. F41 - Peer-to-Peer Device Bypass
A peripheral can produce effects through an alternate hardware path.
That path must be included in the governed effect domain or
separately restricted.
Das Expires 25 April 2027 [Page 393]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.211. F42 - Multi-Device Shared Budget Inconsistency
Two physical devices independently issue the entire budget.
A consistent shared allocator or disjoint sub-budget model is
required.
7.6.212. F43 - Incomplete Recovery Inventory
The controller cannot identify all surviving executable commands.
Uncertain reservations remain charged.
7.6.213. F44 - Unknown Partial Completion
The exact already-effected quantity is unavailable.
The controller retains conservative charged exposure.
7.6.214. F45 - Command Replay Across Epochs
An old command descriptor is submitted under a later recovery
generation.
The admission controller rejects unsupported replay.
7.6.215. F46 - Budget Table Counter Wraparound
A long-running task exceeds numeric counter capacity.
Checked arithmetic or suitably wide counters prevent silent
wraparound.
7.6.216. PART XVII - IMPLEMENTATION VARIATIONS
7.6.217. C-76.126 - Programmable Network Interface Controller
The controller reserves network-transmission budget before admitting
transmit descriptors.
Hardware completion or transmit-boundary evidence reconciles
completed quantities.
7.6.218. C-76.127 - SmartNIC Budget Table
A SmartNIC maintains device-local per-task counters shared across
multiple transmit rings.
Das Expires 25 April 2027 [Page 394]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A protected management processor controls configuration and recovery.
7.6.219. C-76.128 - DPU Admission Service
A DPU hosts the protected accounting service and mediates host-
generated network or storage commands.
The AI host cannot directly modify the authoritative table.
7.6.220. C-76.129 - DMA Queue Manager
The controller budgets destination write quantities before accepting
DMA descriptors.
| The device enforces transfer bounds and reports confirmed completion. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.130 - IOMMU-Associated Admission The IOMMU provides protected address-space isolation while an associated controller implements actual effect-budget reservation. The implementation does not incorrectly equate IOMMU translation with budget enforcement. |
| C-76.131 - GPU or Accelerator Command Queue A device admission controller reserves bounded output or DMA effect quantities before dispatching accelerator commands. Commands with unbounded output may be segmented or rejected. |
| C-76.132 - Storage Controller A storage controller reserves bounded write or mutation quantities before accepting resource- modifying commands. Completion accounting follows the selected storage effect boundary. |
| C-76.133 - Multi-Process Shared Queue Multiple processes submit commands through one physical queue. The controller maps them to appropriate root task budgets. |
7.6.221. C-76.134 - Multi-Queue Shared Controller
Several queue pairs use one protected budget table.
The table supports atomic reservations across the queues.
| C-76.135 - SR-IOV Virtual Function Implementation Multiple virtual functions are associated with protected task identities. Their resource effects are charged to the applicable shared budget. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.136 - Host-Adjacent Protected Controller A trusted host-side controller mediates commands before effect-capable device queues. The controller is isolated from the less-trusted agent execution context. |
| C-76.137 - Controller-Local Protected SRAM Budget counters and command reservations are stored in device-local SRAM with restricted host access. Recovery may use an additional durable authenticated state mechanism. |
| C-76.138 - Persistent Protected Ledger The controller maintains a durable record of completed effects, reservations, and command generations. The ledger is used for restart and failover reconciliation. |
7.6.222. C-76.139 - Distributed Device Budget Allocation
A protected coordination service allocates disjoint device-level
budgets under a task's authorized global limit.
Each device enforces its local allocation.
7.6.223. C-76.140 - Optional DAS Finality Integration
The hardware budget controller may operate alongside a PED and
Finality Sink.
The PED may authorize a command's resource scope.
Das Expires 25 April 2027 [Page 395]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The hardware controller may independently limit cumulative and
outstanding effect quantities.
The present enforcement point(s) 76 family does not require a
portable per-command receipt or separately issued finality
capability.
7.6.224. PART XVIII - REPRESENTATIVE TECHNICAL DATA STRUCTURES
7.6.225. C-76.141 - TaskBudgetRecord
Fields may include:
1. BudgetEntryID. 2. RootTaskID. 3. EffectClass. 4.
AuthorizedLimit. 5. ReservedOutstandingQuantity. 6.
CompletedEffectQuantity. 7. BudgetEpoch. 8. AuthorityGeneration. 9.
AccountingGeneration. 10. RecoveryStatus.
7.6.226. C-76.142 - HardwareCommandRecord
Fields may include:
1. CommandID. 2. RootTaskID. 3. SubmittingContextID. 4. QueueID.
5. EffectClass. 6. DescriptorDigest.
7. AdmissionGeneration. 8. InitialReservation. 9.
RemainingReservation. 10. CompletedQuantity. 11. CommandStatus.
7.6.227. C-76.143 - TaskContextBindingRecord
Fields may include:
1. ContextBindingID. 2. RootTaskID. 3. ProcessOrVMIdentity. 4.
DeviceSubmissionContext. 5. QueueOwnerReference. 6.
PASIDOrVirtualFunctionReference. 7. DelegationReference. 8.
BindingGeneration. 9. BindingStatus.
7.6.228. C-76.144 - EffectQuantityBoundRecord
Fields may include:
1. CommandID. 2. EffectClass. 3. UnitType. 4. MaximumQuantity. 5.
DescriptorLength. 6. SegmentReferences. 7. RepetitionBound. 8.
EstimationMethod. 9. BoundEnforcementReference. 10. BoundStatus.
Das Expires 25 April 2027 [Page 396]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.229. C-76.145 - ProtectedReservationRecord
Fields may include:
1. ReservationID. 2. CommandID. 3. BudgetEntryID.
4. InitialQuantity. 5. RemainingQuantity. 6. CompletedQuantity. 7.
ReleasedUnusedQuantity. 8. ReservationGeneration. 9.
QueuePublicationStatus. 10. ReservationStatus.
7.6.230. C-76.146 - HardwareCompletionRecord
Fields may include:
1. CompletionID. 2. CommandID. 3. DeviceControllerID. 4.
CompletedEffectQuantity. 5. EffectBoundaryClass. 6.
CompletionSequence. 7. CompletionEvidenceReference. 8.
HardwareGeneration. 9. ReconciliationStatus.
7.6.231. C-76.147 - CancellationFenceRecord
Fields may include:
1. FenceID. 2. CommandID. 3. AffectedQueueIDs. 4.
FenceGeneration. 5. ConfirmedCompletedQuantity. 6.
RemainingEffectuationCapability. 7. AlternateQueueReferences. 8.
FenceVerificationStatus. 9. ReservationReleaseStatus.
7.6.232. C-76.148 - DelegatedTaskAccountingRecord
Fields may include:
1. DelegationID. 2. RootTaskID.
3. DescendantContextID. 4. AuthorizedEffectClasses. 5.
SharedBudgetReference. 6. AllocatedSubBudget. 7.
DelegationGeneration. 8. CurrentQueueReferences. 9.
DelegationStatus.
7.6.233. C-76.149 - QueueRecoveryRecord
Fields may include:
1. RecoveryID. 2. DeviceControllerID. 3. RecoveryEpoch. 4.
PersistedBudgetReference. 5. SurvivingQueueReferences. 6.
OutstandingCommandIDs. 7. CompletedEffectReferences. 8.
IndeterminateCommandSet. 9. ReconciliationOutcome. 10.
AdmissionResumeStatus.
Das Expires 25 April 2027 [Page 397]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.234. C-76.150 - FailoverCommandRecord
Fields may include:
1. FailoverID. 2. OriginalCommandID. 3. OriginalQueueID. 4.
StandbyQueueID. 5. RootTaskID. 6. ExistingReservationReference. 7.
AdditionalReservationReference. 8. OriginalExecutionFenceStatus. 9.
FailoverGeneration. 10. FailoverStatus.
7.6.235. C-76.151 - ProtectedAccountingAuditRecord
Fields may include:
1. AuditID. 2. RootTaskID. 3. EffectClass. 4. AuthorizedLimit. 5.
AggregateReservedQuantity. 6. AggregateCompletedQuantity. 7.
CommandReservationReferences. 8. CurrentAccountingGeneration. 9.
InvariantVerificationOutcome. 10. AuditStatus.
7.6.236. PART XIX - ENGINEERING VERIFICATION TESTS
7.6.237. C-76.152 - Proposed Test Matrix
The following are proposed technical verification tests, not
representations of experiments already performed.
7.6.238. Test Condition
T1 Sufficient budget available T2 Budget exhausted T3 Command enters
queue before reservation T4 Exact effect bound available T5
Conservative bound required T6 Effect bound unknown T7 Scatter-gather
descriptor T8 Repeated accelerator operation T9 Host modifies
descriptor after reservation T10 Two queues reserve final unit
concurrently T11 Completed quantity increases T12 Partial command
completion T13 Partial cancellation T14 Cancellation requested
without fence T15 Cancellation acknowledgment duplicated T16
Completion acknowledgment duplicated T17 Completion and cancellation
race T18 Hardware reports quantity exceeding
reservation
7.6.239. Expected result
Command admitted Command denied Admission barrier prevents execution
Correct reservation Sufficient capacity reserved Command rejected or
segmented Aggregate length accounted Maximum effect counted Effect
bound remains enforced Only permitted number admitted Reserved
quantity correspondingly decreases Completed portion remains charged
Only verified remaining portion released Reservation retained No
Das Expires 25 April 2027 [Page 398]
Internet-Draft Kernel-Hardware Execution Finality October 2026
double refund No double charge Accounting remains consistent
Invariant violation detected
T19 Lost completion acknowledgment T20 Command fails before
effectuation T21 Command fails after partial effectuation T22 Two
processes share task T23 Child process created T24 Delegated worker
submits command T25 Worker forges TaskID T26 Two SR-IOV virtual
functions share task T27 Network queue transmission T28 DMA write
command T29 Storage command T30 Accelerator output command T31
Controller-local table unauthorized write T32 Budget increase by
agent T33 Trusted budget update T34 Budget reduction during queued
work T35 Host restart with live device commands T36 Device reset with
uncertain completion T37 VM snapshot restore T38 VM migration T39
Source VM remains active after migration T40 Queue failover T41
Original and standby queue both executable T42 Stale reservation ID
replay T43 Recovery epoch rollback T44 Queue state differs from
persisted table T45 Incomplete recovery inventory T46 Device memory
corruption T47 Counter integer overflow T48 Negative reserved counter
attempted T49 Alternate queue bypass T50 Multiple devices share
global task budget T51 Duplicate command publication T52 Reservation
committed but queue publication
fails T53 Command completes after cancellation
request T54 Cancel acknowledgment arrives before
completion event T55 Effect metric uses wrong unit T56 Descriptor
retirement incorrectly treated as
external completion
Conservative reconciliation Verified unused reservation released
Partial completion retained Shared budget enforced No fresh root
budget Root attribution maintained Submission rejected Aggregate
accounting Defined effect boundary measured Bounded writes reserved
Native completion semantics used Effect quantity bounded Modification
rejected Rejected Versioned authorization New admissions restricted
Reservations preserved Unresolved capacity retained Old budget not
restored as spendable No duplicate global capacity Fence or dual-
execution accounting Existing effect potential accounted Insufficient
single reservation rejected Rejected Detected Reconciliation required
Admissions remain restricted Accounting integrity failure Prevented
Rejected Governed path restricted Coordinated budget allocation
Duplicate identity controlled Safe rollback or reconciliation
Completed effect charged
Das Expires 25 April 2027 [Page 399]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Final quantity reconciled Typed accounting prevents error Effect
boundary distinction enforced
T57 Persistent budget state recovered T58 Delegation revoked T59
Existing command survives delegation
revocation T60 Protected table audit T61 Sub-budget returned to
parent T62 Peer-to-peer hardware path available T63 Queue failover
after partial completion T64 Controller reset during cancellation
Current generation verified Current task binding enforced Outstanding
liability retained Command-level sums reconcile Unused capacity
proven releasable Protected scope limitation identified or path
governed Completed quantity preserved No premature refund
A concrete test harness should specify device architecture, queue
topology, trusted submission identity, effect classes, command
descriptor formats, accounting units, completion semantics,
cancellation fencing, persistence guarantees, and permitted alternate
execution paths.
The tests must inspect actual hardware or controller-enforced
behavior rather than merely verifying software counter values.
7.6.240. PART XX - Enforcement-Point Mapping and Technical
Correspondence
7.6.241. C-76.153 - Independent enforcement point(s) 76
The embodiment provides the following implementation mapping.
enforcement point(s) 76(a): Host execution environment generating or
delegating resource-operation
commands attributable to an AI-agent task.
enforcement point(s) 76(b): Hardware-adjacent admission controller
associated with network, storage,
DMA, accelerator, peripheral, or IOMMU-associated resource
interfaces.
enforcement point(s) 76(c): Protected task-context association
binding commands to root or delegated task
identity.
Das Expires 25 April 2027 [Page 400]
Internet-Draft Kernel-Hardware Execution Finality October 2026
enforcement point(s) 76(d): Hardware-protected effect-accounting
table storing authorized effect class,
budget limit, reserved outstanding quantity, and completed quantity.
enforcement point(s) 76(e): Bounded resource-effect estimator
operating before command admission.
enforcement point(s) 76(f): Atomic reservation engine increasing
outstanding-effect quantity before queue
publication.
enforcement point(s) 76(g): Command-execution controller denying
admission when completed plus
reserved plus new requested exposure would exceed the permitted
limit.
enforcement point(s) 76(h): Completion-reconciliation engine handling
successful completion, partial
completion, cancellation, and failure.
enforcement point(s) 76(i): Delegation-accounting mechanism
associating descendant commands with
originating task budgets.
First concluding requirement: Queued and delegated commands reserve
effect capacity
before producing the governed external effect.
Second concluding requirement: Reserved capacity is released after
cancellation only when
the controller establishes that the corresponding command portion
cannot subsequently complete.
Third concluding requirement: The effect-budget limit is enforced
without mandating
portable per-command validation receipts or separately issued
finality capabilities.
Das Expires 25 April 2027 [Page 401]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.242. C-76.154 - Dependent enforcement point(s) 77: Network and DMA
Queue Admission
The embodiment provides:
1. Programmable network-controller implementations. 2. SmartNIC
protected budget tables. 3. DPU admission services. 4. DMA
controller implementations. 5. Accelerator queue-manager
implementations. 6. Controller-local or hardware-protected
accounting memory. 7. Multiple host-process submission contexts. 8.
Shared root task attribution. 9. Cross-queue atomic reservation. 10.
Virtual-function and device submission-context bindings. 11.
Protected admission before hardware queue effectuation. 12.
Appropriate effect-bound and completion meters.
7.6.243. C-76.155 - Dependent enforcement point(s) 78: Partial
Execution Accounting
The embodiment provides:
1. Initial bounded reservation. 2. Hardware completion evidence.
3. Partial effect quantification. 4. Atomic reserved-to-completed
transfer. 5. Retention of completed-effect charges. 6. Remaining
reservation tracking. 7. Protected execution fencing. 8. Release of
verified unused quantities. 9. Conservative treatment of unknown
progress. 10. Cancellation-completion race handling. 11. Duplicate
refund prevention. 12. Safe recovery from partial failure.
C-76.156 - Dependent enforcement point(s) 79: Recovery and Queue-
State Consistency
The embodiment provides:
1. Persisted protected budget state. 2. Host restart handling. 3.
Controller reset handling. 4. VM snapshot restoration checks. 5. VM
migration accounting transfer. 6. Queue failover management. 7.
Protected recovery generations. 8. Outstanding hardware command
inventory. 9. Alternate execution-path discovery. 10. Original
queue fencing. 11. Reservation reuse prevention. 12. Reconciliation
of completed and outstanding quantities. 13. Conservative retention
of indeterminate liabilities. 14. Safe resumption of admissions.
7.6.244. PART XXI - implementer IMPLEMENTATION REQUIREMENTS
Das Expires 25 April 2027 [Page 402]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.245. C-76.157 - Implementation Checklist
A person having ordinary skill in the art implementing the embodiment
identifies:
1. The host AI-agent execution environment. 2. The originating task
identity. 3. The delegated task identity representation. 4. The
trusted task-association mechanism.
5. The governed hardware resource interface. 6. The effect-capable
hardware queue. 7. The hardware-adjacent admission boundary. 8. The
protected computing base. 9. The protected budget provisioning
authority. 10. The supported effect classes. 11. The resource-
effect units. 12. The exact effectuation boundary for each class.
13. The command descriptor schema. 14. The command effect-bound
estimator. 15. The treatment of unbounded commands. 16. The
protected effect-accounting table. 17. The budget-limit
representation. 18. The reserved-effect counter. 19. The completed-
effect counter. 20. The atomic reservation procedure. 21. The
queue-publication ordering. 22. The reservation-to-command binding.
23. The counter overflow rules. 24. The concurrent queue
coordination. 25. The protected hardware completion observer. 26.
The partial completion reconciliation procedure. 27. The
cancellation request state. 28. The hardware execution fence. 29.
The authoritative non-effectuation condition. 30. The verified
cancellation refund procedure. 31. The duplicate completion-event
control. 32. The duplicate cancellation-event control. 33. The
host-process delegation registry. 34. The shared root task budget.
35. The optional disjoint sub-budget allocation scheme. 36. The
virtual-function or PASID association. 37. The applicable queue
isolation mechanism. 38. The treatment of device-generated effects.
39. The treatment of existing and alternate hardware queues. 40.
The persisted budget-state format. 41. The reset-recovery
generation. 42. The host restart recovery procedure. 43. The
controller reset recovery procedure. 44. The VM migration
coordination. 45. The source-device execution fence. 46. The queue
failover duplicate-prevention procedure. 47. The replay and rollback
protection. 48. The indeterminate command accounting policy. 49.
The post-recovery invariant verification. 50. The protected
accounting audit mechanism. 51. The engineering tests demonstrating
the claimed budget properties.
The selected hardware or protected controller must actually enforce
the described admission, reservation, and completion conditions.
Das Expires 25 April 2027 [Page 403]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A software process that merely observes device activity and
increments an ordinary application counter after commands have
already become effect-capable does not independently establish the
pre-queue hardware budget enforcement of this implementation profile.
7.6.246. C-76.158 - Technical Effect
The disclosed architecture provides a mechanism for enforcing
cumulative resource-effect limits on AI-agent workloads at a hardware
or hardware-adjacent operation boundary.
A command is admitted to a governed effect-capable queue only after a
protected reservation of its bounded effect quantity.
Queued commands therefore consume budget capacity before actual
effectuation.
Completed effects remain charged while outstanding reservations
represent effects that may still occur.
Atomic reservation prevents concurrent producers from independently
consuming the same available budget.
Delegated workers, subordinate processes, and multiple hardware
queues may share an originating task budget.
Partial completion accounting prevents cancellation or failure from
releasing quantities already effected.
Cancellation fencing prevents outstanding reservations from being
refunded while corresponding commands remain executable.
Recovery-generation and queue-continuity mechanisms prevent host
restart, device reset, virtual-machine migration, or queue failover
from restoring capacity already committed to completed or still-
executable work.
The architecture thereby limits resource-effect exposure without
mandating a portable percommand protected validation receipt or
separately issued finality capability.
Its guarantee depends upon the completeness of the governed effect
paths, the accuracy and enforceability of effect bounds, protected
accounting integrity, reliable completion evidence, and correct
recovery coordination.
Das Expires 25 April 2027 [Page 404]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.6.247. C-76.159 - Technical Summary
this implementation profile discloses a hardware-assisted resource-
control system for artificialintelligence-agent workloads.
A processor or host execution environment generates or delegates
resource-operation commands attributable to an identified AI-agent
task.
A hardware-adjacent admission controller mediates submission of those
commands to an effect-capable network, storage, DMA, accelerator, or
peripheral queue.
A protected task-context association mechanism binds submitted
commands to originating or delegated task identities.
A hardware-protected effect-accounting table maintains authorized
effect-budget limits, reserved outstanding-effect quantities, and
completed-effect quantities.
An effect-bound estimator determines a bounded resource-effect
quantity before command admission.
An atomic reservation mechanism increases the outstanding-effect
quantity before making the command eligible for execution.
A command-execution controller rejects admission when the aggregate
completed and reserved quantities, including the proposed new
reservation, would exceed the protected limit.
A completion-reconciliation mechanism transfers confirmed completed
quantities from outstanding reservations into completed-effect
accounting, preserving their budget charge.
Cancellation releases only the remaining quantity that the protected
controller establishes can no longer become effective.
A delegation-accounting mechanism charges descendant process and
worker commands to applicable originating task budgets.
A recovery controller reconciles protected accounting state with
hardware queue entries after host restart, controller reset, virtual-
machine migration, or queue failover.
A protected generation and execution-fencing mechanism prevents old
or duplicated commands from using released or restored reservation
capacity while the corresponding physical operation remains
executable.
Das Expires 25 April 2027 [Page 405]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The system thereby enforces deferred-effect resource budgets close to
the physical or devicemediated effectuation boundary without
requiring a portable per-command validation receipt or separate
finality capability.
MEMORY-CLASS AUTHORITY ISOLATION FOR PERSISTENT ARTIFICIAL-
INTELLIGENCE AGENTS USING TYPED MEMORY ACCESS, SOURCE-CONTEXT
ATTRIBUTION, PROTECTED PROCEDURAL
7.6.247.1. ENROLLMENT, AUTHORITY- PRESERVING DERIVATION, CROSS- TENANT
MEMORY SEGREGATION, AND RETRIEVAL-TIME POLICY REVALIDATION
7.7. Implementation Profile C-84
Source location: original disclosure pages 1470-1554. Source
technical content is presented here for implementation analysis;
numbering reflects the original profile family rather than a
requirement to implement every profile.
EMBODIMENT C-84 COORDINATED KERNEL AND HARDWARE CONTAINMENT OF
ARTIFICIAL-INTELLIGENCE-AGENT WORKLOADS USING EXECUTION- CONTEXT
ATTRIBUTION, MONOTONIC CONTAINMENT
7.7.1. GENERATIONS, SOFTWARE ADMISSION FENCING, DEVICE-LEVEL
EFFECTUATION RESTRICTIONS, IN- FLIGHT COMMAND SETTLEMENT, AND
MIGRATION-SAFE RECOVERY
7.7.2. C-84.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, operating-system containment, kernel-level workload
observation, hardware-assisted isolation, programmable network
interfaces, direct-memory-access control, input/output memory
management, accelerator command processing, storage queue protection,
device-level execution fencing, and recovery-safe security-state
continuity.
More particularly, the embodiment discloses a computer-implemented
containment system configured to respond to a detected security
deviation associated with an artificialintelligence-agent execution
context.
The system coordinates restrictions at two distinct categories of
enforcement boundary:
Das Expires 25 April 2027 [Page 406]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) a software execution-control boundary controlling admission of
new resource-operation commands; and (b) a hardware effectuation
boundary controlling resource operations that may already have been
submitted to, fetched by, or accepted into a device or hardware
queue.
A containment controller assigns a protected containment generation,
identifies the relevant execution context and its accessible
hardware-effectuation interfaces, applies corresponding software and
hardware restrictions, inventories commands capable of further
effectuation,
and determines whether those commands have completed, have been
verifiably canceled, or remain unresolved.
Containment is reported complete only when the required software
restrictions and hardware restrictions have become effective and no
unresolved affected command remains capable of bypassing the intended
containment state.
The architecture further preserves containment restrictions across
host restart, virtualmachine migration, checkpoint restoration, queue
relocation, device reset, and failover.
The invention may be implemented in:
1. AI-agent sandboxes. 2. Containers. 3. Virtual machines. 4.
Micro-VMs. 5. Host operating systems. 6. Hypervisors. 7. Cloud
execution platforms. 8. SmartNICs. 9. Data-processing units. 10.
Programmable network interfaces. 11. DMA controllers. 12. IOMMU-
associated controllers. 13. GPU and accelerator command processors.
14. Storage submission controllers. 15. Privileged peripheral
interfaces. 16. Distributed AI-agent execution systems.
The embodiment does not depend upon a particular operating system,
hypervisor, networkinterface vendor, device architecture, kernel
instrumentation framework, or artificialintelligence model.
The required enforcement and completion guarantees must be provided
by the actual selected platform.
7.7.3. PART I - TECHNICAL PROBLEM
7.7.4. C-84.2 - Detection Is Not Containment
An AI-agent runtime may be monitored using:
(a) kernel events; (b) eBPF instrumentation;
Das Expires 25 April 2027 [Page 407]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(c) Linux Security Module hooks;
(d) hypervisor telemetry;
(e) process execution records;
(f) file-access observations;
(g) network socket events;
(h) resource-operation telemetry; or
(i) protected workload instrumentation.
A monitoring system may detect behavior outside an expected security
profile.
For example:
An AI agent accesses an unauthorized credential.
An AI agent attempts an unexpected outbound connection.
An AI agent submits an unusual DMA command.
An AI agent invokes an unauthorized tool.
Detection establishes that an event occurred or is occurring.
It does not automatically establish that the affected workload can no
longer produce further resource effects.
7.7.5. C-84.3 - Process Termination Is Not Hardware Settlement
A common response to an agent security incident is to terminate the
agent process.
However, process termination may occur after commands have already
been submitted to hardware.
For example:
AGENT PROCESS
→ OPERATING SYSTEM
→ NIC TRANSMIT RING
Das Expires 25 April 2027 [Page 408]
Internet-Draft Kernel-Hardware Execution Finality October 2026
→ NIC DMA FETCH
→ PACKET TRANSMISSION.
Terminating the originating process may prevent some future software
execution.
It does not necessarily cancel descriptors already consumed by the
network device.
Likewise, a storage write, accelerator command, or DMA transfer may
continue after the initiating process has exited.
The architecture therefore distinguishes process termination from
verified hardware containment.
7.7.6. C-84.4 - Pending Network Transmission
An agent may place network data in an operating-system queue or NIC
transmit ring.
At the moment a security incident is detected, different portions may
be:
1. Not yet admitted. 2. Staged in software. 3. Accepted into a
transmit queue. 4. Fetched by the device. 5. Partially transmitted.
6. Fully transmitted. 7. Awaiting an acknowledgment or completion
record.
A request to disable network access may not retroactively stop
packets already transmitted.
The system must record completed transmission separately from packets
verifiably prevented from leaving the controlled interface.
7.7.7. C-84.5 - Outstanding DMA Access
A device may hold access to host memory through an active DMA
mapping.
Revoking a software process's permissions does not necessarily revoke
already established device memory access.
A DMA operation may already be:
(a) queued; (b) fetched;
(c) executing;
Das Expires 25 April 2027 [Page 409]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(d) partially completed;
(e) pending in an interconnect;
(f) awaiting a device completion; or
(g) retained through a device-specific command engine.
The containment system must account for these conditions according to
the actual device and IOMMU completion semantics.
7.7.8. C-84.6 - Accelerator Command Continuation
An AI-agent workload may issue a command to an accelerator.
The command may initiate computation, DMA, persistent output, or
other consequential operations.
The host application can terminate while the accelerator continues
executing admitted work.
The containment controller therefore identifies relevant accelerator
queues and applies supported command-submission restrictions,
cancellation, reset, quiescence, or resourceaccess fencing.
7.7.9. C-84.7 - Multiple Hardware Access Paths
An agent may access:
NIC Queue A.
NIC Queue B.
DMA Engine C.
Storage Queue D.
Accelerator Queue E.
If containment restricts only one path, another may remain capable of
producing effects.
The system identifies the hardware-effectuation interfaces associated
with the affected context.
The coverage requirement applies to the designated containment scope.
Das Expires 25 April 2027 [Page 410]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.10. C-84.8 - Race Between Detection and Restriction
A security event may be detected at time T1.
The containment decision is made at T2.
Software submission may stop at T3.
Hardware restrictions may become effective at T4.
Commands submitted between T1 and T4 may enter hardware queues.
The controller therefore defines a containment generation and
admission-fencing sequence.
It must also account for commands that crossed an enforcement
boundary before the relevant restriction became effective.
7.7.11. C-84.9 - Incomplete Containment Acknowledgment
A network controller may acknowledge receipt of a containment
command.
However, the acknowledgment may mean only that the command was
accepted for processing.
It may not prove that:
1. New transmissions are blocked. 2. Existing queues are drained.
3. DMA access is fenced. 4. Already fetched descriptors are
settled. 5. Alternate queues are restricted. 6. A standby
controller has received the containment generation.
The system distinguishes configuration receipt from effective
enforcement.
7.7.12. C-84.10 - Recovery Can Reintroduce Stale Authority
A host may restore an earlier checkpoint containing:
(a) active device queue configurations;
(b) a process state predating containment;
(c) previously available credentials;
(d) old resource mappings;
Das Expires 25 April 2027 [Page 411]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(e) an earlier access-control policy; or
(f) old device submission descriptors.
A destination host or migrated virtual machine may attempt to resume
normal execution using that stale state.
The embodiment prevents such resumption until the current containment
generation and unresolved-operation state are reconciled.
7.7.13. PART II - CENTRAL TECHNICAL PRINCIPLE
7.7.14. C-84.11 - Containment Must Reach the Effectuation Boundary
The principal requirement is:
7.7.15. Containment of an AI-agent workload is not complete merely
because new software
execution has stopped; previously admitted hardware operations must
also be settled or made incapable of bypassing the required
restrictions.
The system coordinates:
SOFTWARE ADMISSION CONTROL
x
HARDWARE RESOURCE RESTRICTION x
IN-FLIGHT OPERATION INVENTORY
x
SETTLEMENT OR VERIFIED FENCING
x
RECOVERY STATE CONTINUITY.
7.7.16. C-84.12 - Three Required Completion Conditions
For a containment generation G affecting execution context X, define:
S(G,X) = the required software command-admission restrictions are
effective.
Das Expires 25 April 2027 [Page 412]
Internet-Draft Kernel-Hardware Execution Finality October 2026
H(G,X) = the required hardware restrictions are effective.
Q(G,X) = no unresolved affected command remains capable of bypassing
the intended restrictions.
Then:
CONTAINED(G,X) = S(G,X) AND H(G,X) AND Q(G,X).
The containment controller reports completion only after all required
predicates are established.
7.7.17. C-84.13 - Meaning of Unresolved Operation
An operation may be classified as unresolved when its exact
effectuation outcome is not yet known.
However, unresolved outcome and unresolved ability to produce future
effects are different conditions.
A command may have an unknown historical completion result but be
authoritatively fenced from any future effectuation.
Such a command can remain historically indeterminate while satisfying
the applicable nofurther-bypass condition.
Conversely, a command that might still transmit, write, or actuate
cannot be treated as safely settled merely because its execution
outcome is unknown.
7.7.18. C-84.14 - No Retroactive Erasure
Containment does not reverse effects that occurred before the
restriction became effective.
For example:
Packets already transmitted remain transmitted.
DMA writes already completed remain completed.
Storage mutations already committed remain committed.
Physical actuation already performed remains performed.
The system records those effects and prevents or restricts further
effects within its actual enforcement coverage.
Das Expires 25 April 2027 [Page 413]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Post-effect correction may be handled by a separate remediation
architecture.
7.7.19. C-84.15 - No Mandatory Portable Finality Artifact
The embodiment can be implemented through:
1. Runtime observation. 2. Context association. 3. Containment
generations. 4. Kernel-level admission restrictions. 5. Device-
level queue controls. 6. Hardware access mapping restrictions. 7.
Command inventory. 8. Completion and cancellation evidence. 9.
Protected recovery state.
It does not necessarily require a separate portable validation
receipt or individually minted finality capability for every device
command.
Its primary function is coordinated containment following a security
deviation.
7.7.20. PART III - PRINCIPAL SYSTEM COMPONENTS
7.7.21. C-84.16 - Agent Execution Environment
An AI-Agent Execution Environment contains the workload whose
operations are subject to containment.
A representative environment may be:
AGENT_RUNTIME.
CONTAINER.
MICRO_VM.
VIRTUAL_MACHINE.
HOST_PROCESS_GROUP.
DELEGATED_WORKER_GROUP.
ACCELERATOR_EXECUTION_CONTEXT.
The workload may submit resource-operation commands through multiple
software and hardware interfaces.
Das Expires 25 April 2027 [Page 414]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.22. C-84.17 - Runtime Observation Mechanism
A Runtime Observation Mechanism collects security-relevant workload
events.
Possible implementations include:
(a) kernel-level event monitoring; (b) eBPF-based telemetry; (c) LSM-
mediated security events; (d) hypervisor observation; (e) protected
agent runtime telemetry; (f) process and execution-context
monitoring; (g) device command observation; or (h) combinations
thereof.
Observation alone is not treated as an enforcement barrier.
7.7.23. C-84.18 - Execution-Context Association Mechanism
An Execution-Context Association Mechanism maps detected events to
affected workload identities and accessible resource-operation
interfaces.
A representative identity comprises:
BootGeneration.
ProcessNamespace.
ProcessCreationIdentity.
ContainerIdentity.
VirtualMachineIdentity.
AgentTaskID.
ExecutionGeneration.
RelevantDeviceContexts.
The implementation should avoid reliance upon an ordinary process
identifier alone where identifier reuse or process migration could
cause misattribution.
7.7.24. C-84.19 - Resource-Interface Registry
A Resource-Interface Registry identifies hardware and software
effectuation paths accessible to an execution context.
Das Expires 25 April 2027 [Page 415]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Entries may identify:
NetworkQueueID.
NICVirtualFunctionID.
DMAContextID.
IOMMUDomainID.
StorageQueueID.
AcceleratorContextID.
PrivilegedDeviceInterfaceID.
QueueOwner.
ProtectionCapability.
7.7.25. C-84.20 - Containment-Decision Engine
The Containment-Decision Engine determines whether an observed
deviation satisfies a designated containment condition.
Examples include:
UNAUTHORIZED_RESOURCE_ACCESS.
PROTECTED_CREDENTIAL_EXPOSURE.
PROHIBITED_NETWORK_DESTINATION.
UNEXPECTED_PRIVILEGED_TOOL_USE.
UNAPPROVED_DEVICE_COMMAND.
SECURITY_POLICY_DEVIATION.
The decision engine may use deterministic policy, risk scoring, event
correlation, or another defined mechanism.
A score alone is not necessarily sufficient to establish a hardware
restriction unless the applicable containment policy authorizes the
response.
Das Expires 25 April 2027 [Page 416]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.26. C-84.21 - Containment-State Controller
The Containment-State Controller establishes a containment
generation.
A representative record contains:
ContainmentID.
AffectedExecutionContext.
ContainmentGeneration.
RestrictionSet.
AffectedSoftwareInterfaces.
AffectedHardwareInterfaces.
DecisionEvidenceReference.
ContainmentStatus.
7.7.27. C-84.22 - Software Execution-Control Interface
The Software Execution-Control Interface prevents admission of new
affected resourceoperation commands.
Possible enforcement mechanisms include:
1. Kernel permission hooks. 2. Resource-controller command
admission. 3. Agent tool dispatch denial. 4. Protected connector
gating. 5. Hypervisor-mediated I/O submission blocking. 6. Cgroup
or device access restrictions. 7. Controlled queue submission
interfaces. 8. Other enforceable software-side barriers.
An ordinary telemetry-only eBPF program does not automatically
satisfy this requirement.
The selected mechanism must actually prevent applicable commands from
reaching the governed queue.
7.7.28. C-84.23 - Hardware Containment Interface
The Hardware Containment Interface applies restrictions to at least
one designated hardwareeffectuation mechanism.
Representative targets include:
Das Expires 25 April 2027 [Page 417]
Internet-Draft Kernel-Hardware Execution Finality October 2026
NETWORK_TRANSMISSION_QUEUE.
DMA_MAPPING.
STORAGE_SUBMISSION_QUEUE.
ACCELERATOR_COMMAND_QUEUE.
PRIVILEGED_DEVICE_INTERFACE.
HARDWARE_RESOURCE_ACCESS_TABLE.
The interface may rely upon a device driver, hypervisor, privileged
device controller, hardware management processor, or protected
firmware service.
7.7.29. C-84.24 - Network Containment Controller
A Network Containment Controller may:
(a) prevent new affected packet submissions; (b) disable selected
transmit queues; (c) fence queue ownership; (d) stop device
scheduling of pending descriptors; (e) identify transmitted packets;
(f) determine cancelable pending packets; and
(g) coordinate transmit-drain or reset operations.
The controller must use the actual supported NIC semantics.
7.7.30. C-84.25 - DMA and Accelerator Containment Controller
The DMA and Accelerator Containment Controller may:
1. Block new submissions. 2. Fence device command queues. 3.
Revoke or restrict device-access mappings. 4. Synchronize relevant
translation invalidations. 5. Quiesce outstanding DMA operations. 6.
Drain or cancel command work. 7. Record completed operations. 8.
Verify remaining access restrictions.
The controller must not assume that merely updating an IOMMU mapping
synchronously cancels all previously admitted device transactions.
7.7.31. C-84.26 - In-Flight Operation Inventory
An In-Flight Operation Inventory identifies commands that crossed the
software admission boundary before containment became effective.
A representative record includes:
Das Expires 25 April 2027 [Page 418]
Internet-Draft Kernel-Hardware Execution Finality October 2026
CommandID.
ExecutionContextID.
QueueID.
DeviceID.
SubmissionGeneration.
LastKnownCommandState.
PotentialEffectClass.
EffectQuantityBound.
CompletionEvidence.
CancellationEvidence.
7.7.32. C-84.27 - Operation-Settlement Mechanism
The Operation-Settlement Mechanism classifies affected commands as:
COMPLETED.
VERIFIABLY_CANCELED.
UNRESOLVED.
It may also maintain explanatory substates:
PARTIALLY_COMPLETED.
FENCED_PENDING_RECONCILIATION.
COMPLETION_UNKNOWN.
CANCELLATION_REQUESTED.
These substates do not replace the enforcement point's principal
settlement classes.
7.7.33. C-84.28 - Containment-Completion Controller
The Containment-Completion Controller evaluates software restriction
acknowledgments, hardware restriction acknowledgments, and the in-
flight inventory.
Das Expires 25 April 2027 [Page 419]
Internet-Draft Kernel-Hardware Execution Finality October 2026
It reports:
CONTAINED_VERIFIED
only after the applicable completion conditions have been
established.
Other statuses may include:
CONTAINMENT_REQUESTED.
SOFTWARE_RESTRICTED.
HARDWARE_RESTRICTED.
SETTLEMENT_PENDING.
CONTAINMENT_INCOMPLETE.
RECOVERY_RESTRICTED.
7.7.34. C-84.29 - Recovery Controller
A Recovery Controller preserves containment across:
HOST_RESTART.
DEVICE_RESET.
VM_MIGRATION.
CHECKPOINT_RESTORATION.
QUEUE_RELOCATION.
HOST_FAILOVER.
The destination environment does not restore unrestricted resource
access until the transferred state is verified.
7.7.35. C-84.30 - Protected Containment Registry
A Protected Containment Registry maintains current generations,
affected contexts, restriction sets, acknowledged hardware state,
unresolved commands, and recovery status.
Das Expires 25 April 2027 [Page 420]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The registry may be implemented in protected host memory, a trusted
controller, a durable security service, or another protected
execution domain.
The required protection is that a less-trusted AI workload cannot
erase its active containment merely by restarting or modifying
ordinary process state.
7.7.36. PART IV - EXECUTION-CONTEXT ATTRIBUTION
7.7.37. C-84.31 - Stable Execution Identity
A process identifier may be reused.
Accordingly, a representative stable execution identity includes:
HostBootID.
PIDNamespaceID.
ProcessCreationGeneration.
ProcessID.
ContainerOrVMID.
AgentSessionID.
TaskID.
The system may use equivalent native identifiers where available.
7.7.38. C-84.32 - Hardware Context Mapping
An execution context may be associated with:
NetworkSocket.
TransmitQueue.
DeviceVirtualFunction.
PASID.
IOMMUDomain.
AcceleratorStream.
Das Expires 25 April 2027 [Page 421]
Internet-Draft Kernel-Hardware Execution Finality October 2026
StorageSubmissionQueue.
DeviceHandle.
The registry records the association and applicable generation.
7.7.39. C-84.33 - Shared Device Queues
Multiple execution contexts may share one hardware queue.
If an affected agent shares a queue with unrelated authorized
workloads, the controller must determine whether selective
containment is supported.
A command-level or queue-owner distinction may permit selective
restriction.
Where safe selective containment is unavailable, the system may
restrict the whole queue according to the applicable policy.
It must not enforcement point selective containment while
unidentifiable affected commands remain executable.
7.7.40. C-84.34 - Delegated Processes
An agent may spawn workers that submit device commands on its behalf.
The association mechanism may maintain:
RootTaskID.
ParentExecutionContext.
ChildExecutionContext.
DelegationGeneration.
AccessibleDeviceContexts.
Containment may propagate to descendants that retain the relevant
effectuation authority.
7.7.41. C-84.35 - Service-Account Indirection
A host connector may submit commands using a service account.
The originating agent's process identity may not appear directly in
the device descriptor.
Das Expires 25 April 2027 [Page 422]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The correlation mechanism therefore may require connector transaction
identifiers or authenticated task-context propagation.
A shared service identity alone is insufficient to identify which
agent-originated commands should be selectively contained.
7.7.42. C-84.36 - Attribution Failure
If the controller cannot distinguish affected commands from unrelated
commands, it may:
(a) conservatively restrict the shared queue; (b) prevent further
submissions; (c) defer verified containment completion; (d) invoke a
broader authorized device restriction; or (e) escalate.
The system must not invent precise attribution from incomplete
telemetry.
7.7.43. PART V - SECURITY DEVIATION AND CONTAINMENT DECISION
7.7.44. C-84.37 - Runtime Security Event
A representative event comprises:
SecurityEventID.
EventClass.
ObservedExecutionContext.
ObservedResource.
ObservedOperation.
ObservationSource.
EventGeneration.
PolicyReference.
EvidenceReference.
7.7.45. C-84.38 - Kernel Observation
A kernel monitor may observe an attempted resource access or process
event.
Das Expires 25 April 2027 [Page 423]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The system must distinguish an attempted operation from a completed
resource effect.
For example, a file-open attempt does not by itself prove that file
contents were disclosed.
Likewise, a socket connection attempt does not prove that all queued
payload data was transmitted.
7.7.46. C-84.39 - eBPF Observation
An eBPF program may observe relevant kernel events through supported
attachment points.
Depending upon the kernel and attachment type, some eBPF programs are
observational, while others may participate in specific enforcement
hooks.
The embodiment does not assume all eBPF tracing programs possess
denial authority.
An observational program may trigger a separate containment
controller with actual kernel and hardware restriction capabilities.
7.7.47. C-84.40 - Hypervisor Observation
A hypervisor may detect activity involving:
1. Virtual device configuration. 2. 3. 4. 5. 6.
Guest execution. Memory-access mappings. Virtual I/O queues.
Device assignment. VM state changes.
The hypervisor may apply or coordinate restrictions where it actually
controls the relevant submission or mapping boundary.
7.7.48. C-84.41 - Containment Condition
A security condition may be represented as:
IF ObservedEvent satisfies PolicyCondition
THEN EstablishContainmentGeneration.
The response may depend upon:
Das Expires 25 April 2027 [Page 424]
Internet-Draft Kernel-Hardware Execution Finality October 2026
(a) event severity; (b) affected resource; (c) agent identity; (d)
available effectuation paths; (e) active commands; and (f)
containment policy.
7.7.49. C-84.42 - Scope of Containment
A containment decision may target:
ONE_PROCESS.
ONE_AGENT_TASK.
ONE_CONTAINER.
ONE_VM.
ONE_DELEGATED_WORKER_GROUP.
ONE_DEVICE_CONTEXT.
ONE_TENANT_RESOURCE_DOMAIN.
The controller resolves the selected scope into concrete software and
hardware restriction targets.
7.7.50. PART VI - CONTAINMENT GENERATION AND STATE MACHINE
7.7.51. C-84.43 - Containment Generation
A Containment Generation identifies the current restrictive state
applied to a workload.
For example:
ContainmentGeneration = 47.
AffectedTask = TASK-204.
RestrictionSet = { DENY_NEW_NETWORK_TX, FENCE_DMA_QUEUE,
SUSPEND_ACCELERATOR_SUBMISSION }.
7.7.52. C-84.44 - Monotonic Generation
A protected generation is monotonically ordered within its defined
continuity domain.
A later active containment generation supersedes an earlier
permissive configuration.
Das Expires 25 April 2027 [Page 425]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A stale configuration cannot restore normal access merely by carrying
an old generation number.
7.7.53. C-84.45 - Containment State Machine
A representative state machine is:
NORMAL
→ DEVIATION_DETECTED
→ CONTAINMENT_REQUESTED
→ SOFTWARE_FENCING
→ HARDWARE_FENCING
→ IN_FLIGHT_SETTLEMENT
→ CONTAINED_VERIFIED.
Failure states may include:
CONTAINMENT_INCOMPLETE.
HARDWARE_UNAVAILABLE.
UNRESOLVED_COMMANDS.
RECOVERY_RESTRICTED.
7.7.54. C-84.46 - Restriction Commitment
The controller commits:
1. Affected execution context. 2. New containment generation. 3.
Required software restrictions. 4. Required hardware restrictions.
5. Resource-interface inventory. 6. Initial outstanding-command
state.
The protected commitment occurs before the system relies upon the new
containment status.
7.7.55. C-84.47 - Restriction Distribution
Software and hardware controllers receive the containment generation.
An acknowledgment identifies:
Das Expires 25 April 2027 [Page 426]
Internet-Draft Kernel-Hardware Execution Finality October 2026
ControllerID.
AppliedGeneration.
AppliedRestrictionSet.
EffectiveStatus.
OutstandingCommandReference.
AcknowledgmentEvidence.
7.7.56. C-84.48 - Receipt Versus Enforcement
A controller may acknowledge:
REQUEST_RECEIVED.
CONFIGURATION_STAGED.
RESTRICTION_APPLIED.
RESTRICTION_EFFECTIVE.
These are different states.
The containment-completion controller requires evidence corresponding
to the relevant effective restriction, not merely request receipt.
7.7.57. C-84.49 - Restriction Race
A new command may arrive while containment is being established.
A representative implementation places the software admission gate
into a restrictive state promptly and inventories all commands
admitted before the gate's effective cutoff generation.
The hardware controller then fences the corresponding queues.
The system establishes an ordering relationship between admission
closure and the in-flight inventory.
7.7.58. PART VII - SOFTWARE COMMAND ADMISSION FENCING
7.7.59. C-84.50 - Admission Boundary
The software interface controls new commands submitted through
designated resourceoperation paths.
Das Expires 25 April 2027 [Page 427]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Examples include:
NETWORK_SEND.
DMA_SUBMIT.
STORAGE_WRITE_SUBMIT.
ACCELERATOR_DISPATCH.
DEVICE_CONTROL.
PRIVILEGED_CONNECTOR_REQUEST.
7.7.60. C-84.51 - Software Restriction Rule
A representative rule is:
IF Command.ExecutionContext belongs to AffectedSet
AND Command.EffectClass belongs to RestrictedSet
AND CurrentContainmentGeneration ≥ RequiredGeneration
THEN DENY_ADMISSION.
7.7.61. C-84.52 - Protected Admission Generation
Each software admission decision may be associated with a generation.
Commands admitted before the restrictive cutoff are included in the
outstanding-command accounting domain.
Commands arriving after the effective cutoff are denied.
7.7.62. C-84.53 - Kernel Hook Enforcement
A kernel-level hook may deny relevant operations at a supported
enforcement point.
For example, a suitable LSM hook or resource-control mechanism may
prevent specified device interactions.
The implementation must identify the actual controlled interface and
not assume that a generic process-monitoring event blocks every
possible hardware submission path.
Das Expires 25 April 2027 [Page 428]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.63. C-84.54 - Device Driver Submission Control
A device driver may reject new submissions associated with a
contained context.
For example:
A contained GPU context may be prohibited from submitting new
execution buffers.
The driver-level restriction must be effective against the relevant
submission route, including alternative queues and delegated contexts
within scope.
7.7.64. C-84.55 - Hypervisor Submission Control
A hypervisor may prohibit a contained VM from creating new affected
virtual device submissions.
Where a device is passed through directly, the hypervisor must also
coordinate the applicable hardware mapping or queue restrictions.
7.7.65. C-84.56 - Software Fence Acknowledgment
The software controller reports effective enforcement status and the
associated generation.
The containment controller does not assume the restriction has taken
effect merely because a rule was requested.
7.7.66. PART VIII - HARDWARE CONTAINMENT
7.7.67. C-84.57 - Hardware Restriction Scope
The hardware controller may restrict:
(a) new queue entries; (b) queue scheduling; (c) descriptor fetching;
(d) memory-access mappings;
(e) hardware resource permissions;
(f) accelerator execution contexts;
(g) virtual-function access;
(h) privileged device commands.
Das Expires 25 April 2027 [Page 429]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.68. C-84.58 - Device Restriction Semantics
Different devices provide different capabilities.
A device may support:
STOP_NEW_SUBMISSIONS.
PAUSE_QUEUE.
DRAIN_QUEUE.
CANCEL_PENDING.
ABORT_CONTEXT.
RESET_ENGINE.
INVALIDATE_MAPPING.
FENCE_ACCESS.
The selected operation must provide the required security effect
according to device documentation and verified behavior.
7.7.69. C-84.59 - Hardware Restriction Acknowledgment
A protected or authoritative controller may report:
DeviceID.
QueueID.
ContainmentGeneration.
RestrictionOperation.
EffectiveBarrierSequence.
PendingCommandCount.
OutstandingAccessState.
RestrictionStatus.
The containment-completion controller evaluates this information
against the required restriction set.
Das Expires 25 April 2027 [Page 430]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.70. C-84.60 - Queue Stop Versus Queue Drain
Stopping new queue dispatch is not necessarily equivalent to draining
in-flight operations.
A queue may be stopped while the device still processes commands
already fetched.
The controller therefore separately evaluates outstanding work.
7.7.71. C-84.61 - Hardware Reset
A reset may terminate some device execution.
However, its precise effects depend upon the device and interconnect.
A reset acknowledgment does not universally prove that every
previously issued memory write or network transmission was canceled.
The controller uses the relevant completion and fencing semantics to
establish the required result.
7.7.72. PART IX - NETWORK TRANSMISSION
7.7.73. CONTAINMENT
7.7.74. C-84.62 - Network Effect Boundary
For enforcement point(s) 85, the network containment mechanism
distinguishes packets that have irreversibly left the controlled
interface from packets still preventable from transmission.
The implementation must define the observable transmission boundary.
For example:
NIC_EGRESS_BOUNDARY.
PHYSICAL_TRANSMIT_COMPLETION.
ANOTHER_VERIFIABLE_DEVICE_EGRESS_STATE.
Transmission from the NIC does not automatically prove receipt by a
remote application.
Das Expires 25 April 2027 [Page 431]
Internet-Draft Kernel-Hardware Execution Finality October 2026
| C-84.63 - Network Queue Inventory The controller identifies: 1. Transmit descriptors not yet fetched. 2. Device-fetched descriptors. 3. Packets scheduled for transmission. 4. Partially transmitted data. 5. Packets already transmitted. 6. Packets canceled before transmission. 7. Commands with uncertain completion. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-84.64 - Preventing New Network Submission The software controller denies new affected send operations. The hardware controller prevents the affected queue from accepting or executing further work beyond the permitted containment policy. Both restrictions may be necessary. |
| C-84.65 - Pending Packet Cancellation Where the NIC supports cancellation of queued packets, the controller requests cancellation. It verifies that the packets were prevented from crossing the defined egress boundary. A packet removed from host software memory is not necessarily canceled if its descriptor was already fetched. |
7.7.75. C-84.66 - Already Transmitted Packets
Packets already transmitted are recorded separately.
They are not included among verifiably canceled packets.
The system may retain:
PacketOrDescriptorID.
TransmitQueueID.
EffectQuantity.
TransmissionEvidence.
TransmissionStatus.
7.7.76. C-84.67 - Partial Network Completion
A command may represent several packets or a segmented transmission.
Some packets may have transmitted while others remain queued.
The controller accounts separately for the completed and canceled
portions.
7.7.77. C-84.68 - Packet Transmission Race
A packet may leave the NIC while containment is being applied.
The controller establishes whether the packet crossed the egress
boundary before the effective restriction.
It does not retroactively classify the packet as canceled.
7.7.78. C-84.69 - Shared Network Interface
A SmartNIC may serve several workloads.
The containment controller may use per-queue, per-virtual-function,
per-tenant, or percommand restrictions.
Das Expires 25 April 2027 [Page 432]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Where the device does not support sufficiently precise isolation,
broader interface restriction may be required.
7.7.79. PART X - DMA AND IOMMU CONTAINMENT
7.7.80. C-84.70 - DMA Access Context
A DMA operation may be associated with:
DeviceID.
PASID.
IOMMUDomain.
AddressSpaceID.
CommandID.
QueueID.
TransferRange.
SubmissionGeneration.
7.7.81. C-84.71 - Mapping Revocation
An IOMMU-related controller may invalidate or remove a mapping
permitting a device to access selected memory.
The implementation must consider whether:
(a) the device caches address translations; (b) invalidation
acknowledgment is required; (c) transactions already issued may still
complete; (d) outstanding posted writes exist; (e) alternate mappings
remain valid; and
(f) an ATS or related device translation facility is in use.
7.7.82. C-84.72 - Mapping Invalidation Is Not Always Quiescence
| A mapping update may prevent future address translations. It does not necessarily prove that all previously translated or issued accesses have settled. The containment-completion controller therefore requires the applicable device and interconnect quiescence or completion evidence. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-84.73 - DMA Queue Fencing The controller may: 1. Deny new DMA descriptors. 2. Suspend queue processing. 3. Abort supported pending descriptors. 4. Revoke device access. 5. Synchronize mapping invalidations. 6. Await outstanding completion. 7. Record unresolved accesses. |
| C-84.74 - Partially Completed DMA A DMA command may write only part of its target region before containment. The system records confirmed completed portions where available. It does not claim that already written memory has automatically returned to its earlier state. If correction is necessary, it constitutes a separate resource-state remediation operation. |
Das Expires 25 April 2027 [Page 433]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.83. C-84.75 - Device Translation Cache
A device may retain translations or other access state beyond the
host's immediate mapping modification.
The controller applies the required invalidation and synchronization
protocol.
Containment remains incomplete where the device may continue making
unauthorized accesses.
7.7.84. C-84.76 - Unresolved DMA Access
If a DMA operation may still access protected memory and no effective
fence is established, the command remains an unresolved containment
blocker.
The controller cannot report full containment merely because the host
process has been terminated.
7.7.85. PART XI - ACCELERATOR CONTAINMENT
7.7.86. C-84.77 - Accelerator Command Context
A GPU or other accelerator may maintain:
ExecutionContextID.
CommandQueueID.
CommandBufferID.
DMAOutputReference.
DeviceMemoryMapping.
SubmissionGeneration.
OutstandingWorkCount.
7.7.87. C-84.78 - New Accelerator Submission Restriction
The software controller blocks new affected command buffers or kernel
submissions.
The accelerator controller restricts the corresponding hardware
execution queue.
Das Expires 25 April 2027 [Page 434]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.88. C-84.79 - Already Executing Accelerator Work
| An accelerator operation may continue after host submission is blocked. The controller determines whether the supported hardware can: (a) preempt the operation; (b) suspend the context; (c) abort the command; (d) fence output access; (e) wait for completion; or (f) reset the relevant engine. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-84.80 - Output Effect Isolation A running accelerator may produce outputs in device-local memory. Whether this constitutes an external resource effect depends upon the selected boundary. For example, a kernel producing private intermediate registers may be less consequential than one completing a DMA write to a protected host resource. The controller identifies which output interfaces must be contained. |
| C-84.81 - Shared Accelerator Several agents may use a shared accelerator. The controller must identify which commands belong to the affected execution context. If command-level selective cancellation is unavailable, the implementation may require a broader hardware reset or queue restriction. |
7.7.89. PART XII - IN-FLIGHT OPERATION INVENTORY
7.7.90. C-84.82 - Inventory Purpose
The inventory identifies previously admitted commands that may still
produce effects after containment begins.
The inventory is not restricted to commands still visible in an
ordinary host process queue.
It may include device-fetched or downstream queued work.
7.7.91. C-84.83 - Command State
A representative command state comprises:
NOT_SUBMITTED.
SOFTWARE_STAGED.
HARDWARE_QUEUED.
DEVICE_FETCHED.
EXECUTING.
PARTIALLY_COMPLETED.
COMPLETED.
CANCELLATION_REQUESTED.
VERIFIABLY_CANCELED.
UNRESOLVED.
7.7.92. C-84.84 - Inventory Cutoff
The system establishes a cutoff associated with the effective
software admission fence.
Das Expires 25 April 2027 [Page 435]
Internet-Draft Kernel-Hardware Execution Finality October 2026
All commands admitted before the cutoff that remain potentially
executable must be accounted for.
A command cannot be omitted merely because its initiating process has
exited.
7.7.93. C-84.85 - Queue Enumeration
The controller queries applicable queue or device state.
It may use:
Driver submission ledgers.
Hardware descriptor indexes.
Queue producer-consumer pointers.
Completion rings.
Device context tables.
DMA tracking state.
Accelerator work registries.
Protected submission records.
7.7.94. C-84.86 - Inventory Completeness
The controller establishes whether the inventory covers all affected
queues and resource interfaces required by the containment policy.
If a necessary queue cannot be inspected, the controller may require
a broader execution fence or mark containment incomplete.
7.7.95. C-84.87 - Command Identity
Each command may have a protected or uniquely associated identity.
A representative identity comprises:
DeviceID.
QueueID.
CommandGeneration.
Das Expires 25 April 2027 [Page 436]
Internet-Draft Kernel-Hardware Execution Finality October 2026
DescriptorSequence.
ExecutionContextID.
LogicalOperationID.
This supports settlement and prevents duplicate accounting.
7.7.96. PART XIII - OPERATION SETTLEMENT
7.7.97. C-84.88 - Completed Operation
A command is classified COMPLETED when authoritative evidence
establishes its completion according to the selected effect boundary.
The completed effect remains recorded.
7.7.98. C-84.89 - Verifiably Canceled Operation
A command is classified VERIFIABLY_CANCELED when the controller
establishes that its remaining relevant effect cannot occur.
Evidence may include:
1. An authoritative hardware cancellation. 2. An effective command
execution fence. 3. Queue removal plus proof of non-fetch. 4.
Device context quiescence. 5. Required DMA invalidation and
outstanding-access settlement. 6. Other native device proof of non-
effectuation.
7.7.99. C-84.90 - Unresolved Operation
An operation is UNRESOLVED when the system lacks sufficient evidence
to classify completion or cancellation.
The controller additionally determines whether the unresolved command
remains capable of bypassing the containment restrictions.
7.7.100. C-84.91 - Unresolved but Fenced
A command may have unknown historical completion status while the
affected device context is now fully fenced.
The controller may record:
SettlementClass = UNRESOLVED.
FutureBypassCapability = VERIFIED_ABSENT.
Das Expires 25 April 2027 [Page 437]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Such a command does not necessarily block the no-further-bypass
condition, but it remains unresolved for historical accounting or
remediation.
7.7.101. C-84.92 - Unresolved and Still Executable
A command may remain:
SettlementClass = UNRESOLVED.
FutureBypassCapability = POSSIBLE.
In this case, verified containment is withheld.
7.7.102. C-84.93 - Settlement Record
A representative record comprises:
CommandID.
ContainmentGeneration.
EffectClass.
LastObservedState.
CompletedEffectReference.
CancellationEvidenceReference.
FutureExecutionCapability.
SettlementClass.
SettlementGeneration.
7.7.103. C-84.94 - Settlement Race
Completion and cancellation evidence may arrive concurrently.
The settlement mechanism serializes state updates and prevents a
command from being simultaneously recorded as wholly completed and
wholly canceled contrary to actual partialeffect evidence.
7.7.104. PART XIV - VERIFIED CONTAINMENT COMPLETION
Das Expires 25 April 2027 [Page 438]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.105. C-84.95 - Completion Barrier
The containment-completion controller evaluates:
SOFTWARE_FENCE_EFFECTIVE.
HARDWARE_RESTRICTIONS_EFFECTIVE.
IN_FLIGHT_BYPASS_ABSENT.
All three must hold.
7.7.106. C-84.96 - Software Restriction Evidence
The evidence identifies:
AppliedContainmentGeneration.
AffectedExecutionContext.
RestrictedOperationClasses.
EffectiveAdmissionCutoff.
EnforcementController.
VerificationStatus.
7.7.107. C-84.97 - Hardware Restriction Evidence
The evidence identifies:
DeviceID.
AffectedQueueOrMapping.
AppliedContainmentGeneration.
RestrictionClass.
RestrictionEffectiveState.
OutstandingAccessStatus.
VerificationStatus.
Das Expires 25 April 2027 [Page 439]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.108. C-84.98 - In-Flight Settlement Evidence
The evidence identifies:
1. Previously admitted commands. 2. Confirmed completed effects. 3.
Verified canceled commands. 4. Unresolved operations. 5. Commands
incapable of future effectuation. 6. Commands still capable of
bypass.
7.7.109. C-84.99 - Completion Decision
A containment-completion controller may return:
CONTAINED_VERIFIED.
CONTAINMENT_INCOMPLETE.
SETTLEMENT_PENDING.
HARDWARE_RESTRICTION_UNVERIFIED.
SOFTWARE_RESTRICTION_UNVERIFIED.
RECOVERY_RESTRICTED.
A favorable response requires the specified effective conditions.
7.7.110. C-84.100 - Unknown Hardware State
Where required hardware state is unknown, the controller does not
declare verified containment solely because no further events are
observed.
Absence of telemetry is not proof of quiescence.
7.7.111. C-84.101 - Containment Scope Report
A containment report may identify:
ContainmentGeneration.
AffectedExecutionContexts.
RestrictedSoftwarePaths.
RestrictedHardwarePaths.
CompletedOperations.
Das Expires 25 April 2027 [Page 440]
Internet-Draft Kernel-Hardware Execution Finality October 2026
CanceledOperations.
UnresolvedOperations.
ResidualHistoricalEffects.
VerificationStatus.
The report should distinguish the covered scope from uncontrolled
systems or external destinations.
7.7.112. PART XV - MIGRATION, RESTART, AND FAILOVER
7.7.113. C-84.102 - Containment Across Host Restart
A restarted host may recreate process or device state.
Before allowing normal execution, the Recovery Controller checks the
protected current containment generation.
Old process state does not override the active restriction.
7.7.114. C-84.103 - Checkpoint Restoration
A restored checkpoint may contain:
Old device mappings.
Old queue registrations.
Old process permissions.
Old network configuration.
The restore mechanism applies or reconciles the current containment
generation before enabling effect-capable interfaces.
7.7.115. C-84.104 - Virtual-Machine Migration
A migrating VM may contain an affected agent workload.
The destination receives:
AffectedExecutionContext.
ContainmentGeneration.
RestrictionSet.
Das Expires 25 April 2027 [Page 441]
Internet-Draft Kernel-Hardware Execution Finality October 2026
InFlightCommandState.
RelevantDeviceMappings.
VerificationStatus.
The destination applies and verifies the required restrictions before
normal resumption.
7.7.116. C-84.105 - Source-Host Fencing
A migrated workload may remain partly executable at the source host.
The migration protocol must ensure that the old and new environments
cannot both execute affected commands in violation of the containment
state.
The source may be fenced before destination activation.
If source state cannot be conclusively determined, destination
resumption remains restricted according to the policy.
7.7.117. C-84.106 - Queue Relocation
A queue may move to a different hardware controller.
The new controller receives or reconstructs the active containment
generation.
Previously restricted commands are not reclassified as unrestricted
solely because their queue identity changed.
7.7.118. C-84.107 - Hardware Failover
A standby device may take over a resource-operation queue.
Before accepting normal commands, the standby verifies the current
containment restrictions.
Old failover snapshots or queue descriptors must not restore an
unrestricted execution state.
7.7.119. C-84.108 - Device Reset Recovery
Following a device reset, the Recovery Controller identifies:
1. Current containment generation. 2. Surviving mappings. 3.
Recreated queues.
Das Expires 25 April 2027 [Page 442]
Internet-Draft Kernel-Hardware Execution Finality October 2026
4. Previously admitted command status. 5. Unresolved effects. 6.
Current hardware restriction state.
Normal operation remains restricted until consistency is established.
7.7.120. C-84.109 - Containment Generation Rollback
A checkpoint or database snapshot may restore an earlier generation.
The protected registry or generation authority rejects an obsolete
state where a later containment remains active.
7.7.121. C-84.110 - Recovery Restriction
A destination environment may accept migrated data for recovery
purposes without allowing unrestricted effectuation.
For example:
Memory state may be restored.
Device queues may remain disabled.
Native resource access may remain denied.
Containment verification must precede normal effect-capable
execution.
7.7.122. PART XVI - PRINCIPAL 40-STEP
7.7.123. WORKFLOW
7.7.124. C-84.111 - Complete Containment Workflow
7.7.125. Step C84-01 - Agent environment initialization
The system establishes identifiable agent execution contexts and
relevant resource-operation interfaces.
7.7.126. Step C84-02 - Device association registration
Accessible queues, mappings, and hardware control interfaces are
associated with their execution contexts.
7.7.127. Step C84-03 - Runtime observation
A kernel, eBPF, hypervisor, or protected telemetry mechanism observes
security-relevant events.
Das Expires 25 April 2027 [Page 443]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.128. Step C84-04 - Security event normalization
An observed event is converted into a machine-readable event record.
7.7.129. Step C84-05 - Execution context attribution
The event is associated with the affected agent or delegated
workload.
7.7.130. Step C84-06 - Containment-condition evaluation
The decision engine determines whether the event satisfies a
designated security condition.
7.7.131. Step C84-07 - Affected resource scope determination
The controller identifies resource-operation classes and interfaces
requiring restriction.
7.7.132. Step C84-08 - Containment generation allocation
A new protected containment generation is assigned.
7.7.133. Step C84-09 - Containment state commitment
The affected context and restriction set are recorded.
7.7.134. Step C84-10 - Software admission restriction issuance
The software controller is instructed to stop admitting new affected
commands.
7.7.135. Step C84-11 - Software enforcement activation
The required kernel, hypervisor, driver, or tool-dispatch restriction
becomes effective.
7.7.136. Step C84-12 - Software fence acknowledgment
The controller obtains effective restriction evidence and an
admission cutoff.
7.7.137. Step C84-13 - Hardware interface enumeration
The system identifies relevant NIC, DMA, storage, accelerator, and
device interfaces.
Das Expires 25 April 2027 [Page 444]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.138. Step C84-14 - Hardware restriction issuance
Corresponding device restrictions are requested.
7.7.139. Step C84-15 - Hardware restriction application
Device queues and mappings are restricted.
7.7.140. Step C84-16 - Hardware effective-state verification
The controller confirms the required hardware barriers are active.
7.7.141. Step C84-17 - Pre-fence command inventory
Commands admitted before the software cutoff are identified.
7.7.142. Step C84-18 - Queue ownership reconciliation
Relevant driver and hardware command states are reconciled.
7.7.143. Step C84-19 - Command identity verification
Command records are associated with the affected execution context.
7.7.144. Step C84-20 - Completed operation identification
Confirmed completed commands are classified.
7.7.145. Step C84-21 - Pending operation identification
Commands that have not completed are identified.
7.7.146. Step C84-22 - Supported cancellation evaluation
The controller determines which pending operations can be canceled.
7.7.147. Step C84-23 - Network queue settlement
Affected packets are classified as transmitted, canceled, or
unresolved.
7.7.148. Step C84-24 - DMA access settlement
Outstanding memory accesses are quiesced, completed, or canceled
where supported.
Das Expires 25 April 2027 [Page 445]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.149. Step C84-25 - Accelerator settlement
Applicable accelerator commands are drained, canceled, or otherwise
fenced.
7.7.150. Step C84-26 - Partial completion reconciliation
Completed portions of affected commands are recorded.
7.7.151. Step C84-27 - Residual command capability evaluation
The controller determines whether any unresolved command can still
bypass containment.
7.7.152. Step C84-28 - Broader restriction if required
Where selective control is insufficient, a suitable broader hardware
restriction is applied.
7.7.153. Step C84-29 - Final software verification
The software restriction is confirmed current.
7.7.154. Step C84-30 - Final hardware verification
The hardware restriction is confirmed current.
7.7.155. Step C84-31 - In-flight bypass verification
The controller verifies that no unresolved affected command remains
capable of bypass.
7.7.156. Step C84-32 - Containment completion decision
The controller reports verified containment or an incomplete status.
7.7.157. Step C84-33 - Containment evidence commitment
Applied generations, command states, and verification references are
recorded.
7.7.158. Step C84-34 - Restart or migration detection
The system detects an applicable recovery transition.
Das Expires 25 April 2027 [Page 446]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.159. Step C84-35 - Protected generation retrieval
The current containment generation is obtained from the protected
registry.
7.7.160. Step C84-36 - Destination restriction application
The destination environment installs the required restrictions.
7.7.161. Step C84-37 - Outstanding operation reconciliation
Migrated or surviving commands are inventoried and reconciled.
7.7.162. Step C84-38 - Destination consistency verification
The current queues and mappings are checked against the transferred
containment state.
7.7.163. Step C84-39 - Restricted or authorized resumption
The destination permits only execution consistent with the verified
containment generation.
7.7.164. Step C84-40 - Recovery audit commitment
The final recovery and containment state is recorded.
7.7.165. PART XVII - REFERENCE IMPLEMENTATION ALGORITHMS
7.7.166. C-84.112 - Algorithm A: Security Event Attribution
Das Expires 25 April 2027 [Page 447]
Internet-Draft Kernel-Hardware Execution Finality October 2026
function AssociateSecurityEventWithAgent(event):
source = VerifyObservationSource(event)
if source is invalid:
return UNVERIFIED_EVENT
identity = ResolveStableExecutionIdentity({
host_boot_id: event.host_boot_id,
process_namespace: event.pid_namespace,
process_creation_id: event.creation_id,
container_or_vm_id: event.workload_id,
task_reference: event.task_id
})
if identity is unresolved:
return ATTRIBUTION_INCOMPLETE
interfaces = ResourceInterfaceRegistry.lookup(
identity
)
return {
execution_context: identity,
hardware_interfaces: interfaces,
event_reference: event.id
}
A process identifier alone is not necessarily a stable workload
identity.
7.7.167. C-84.113 - Algorithm B: Containment Decision
function EvaluateContainmentCondition(
security_event,
execution_context
):
policy = ResolveCurrentContainmentPolicy(
execution_context
)
outcome = EvaluateSecurityDeviation(
security_event,
policy
)
if outcome does not satisfy containment_condition:
return NO_CONTAINMENT_REQUIRED
Das Expires 25 April 2027 [Page 448]
Internet-Draft Kernel-Hardware Execution Finality October 2026
restriction_set = DeriveAffectedRestrictions({
event: security_event,
context: execution_context,
policy: policy
})
return {
decision: CONTAINMENT_REQUIRED,
restrictions: restriction_set
}
7.7.168. C-84.114 - Algorithm C: Establish Protected Containment
Generation
function EstablishContainment(
execution_context,
restriction_set
):
begin protected_transaction
generation = AdvanceMonotonicContainmentGeneration(
execution_context
)
containment_id = AllocateContainmentID()
record = ProtectedContainmentRegistry.commit({
containment_id: containment_id,
execution_context: execution_context,
generation: generation,
restrictions: restriction_set,
state: CONTAINMENT_REQUESTED
})
commit protected_transaction
return record
The agent cannot select an earlier permissive generation.
7.7.169. C-84.115 - Algorithm D: Software Command Admission Fence
function ApplySoftwareContainment(containment):
targets = ResolveSoftwareAdmissionInterfaces(
containment.execution_context,
containment.restrictions
)
acknowledgments = EmptySet()
for each target in targets:
Das Expires 25 April 2027 [Page 449]
Internet-Draft Kernel-Hardware Execution Finality October 2026
result = target.applyRestriction({
context: containment.execution_context,
generation: containment.generation,
denied_operation_classes:
containment.restrictions
})
acknowledgments.add(result)
if not AllRequiredRestrictionsEffective(
acknowledgments,
containment.generation
):
return SOFTWARE_FENCE_INCOMPLETE
cutoff = ResolveAuthoritativeAdmissionCutoff(
acknowledgments
)
return {
status: SOFTWARE_FENCE_EFFECTIVE,
admission_cutoff: cutoff
}
The admission cutoff is used to identify commands requiring hardware
settlement.
7.7.170. C-84.116 - Algorithm E: Hardware Restriction Application
function ApplyHardwareContainment(containment):
interfaces = ResourceInterfaceRegistry.lookup(
containment.execution_context
)
results = EmptySet()
for each interface in interfaces:
if not InterfaceAffectedByRestriction(
interface,
containment.restrictions
):
continue
Das Expires 25 April 2027 [Page 450]
Internet-Draft Kernel-Hardware Execution Finality October 2026
result = HardwareControlService.apply({
interface_id: interface.id,
containment_generation: containment.generation,
restriction: ResolveDeviceRestriction(
interface,
containment
)
})
results.add(result)
if not VerifyRequiredHardwareEffectiveState(
results,
containment.generation
):
return HARDWARE_FENCE_INCOMPLETE
return HARDWARE_RESTRICTIONS_EFFECTIVE
An acknowledgment of a requested configuration is not necessarily
evidence of effective hardware fencing.
7.7.171. C-84.117 - Algorithm F: In-Flight Command Inventory
function InventoryAffectedCommands(
containment,
software_cutoff
):
interfaces = ResourceInterfaceRegistry.lookup(
containment.execution_context
)
inventory = EmptySet()
for each interface in interfaces:
commands = QueryAuthoritativeCommandState({
interface: interface,
execution_context:
containment.execution_context,
admitted_before: software_cutoff
})
if commands are unavailable:
inventory.markIncomplete(interface)
continue
for each command in commands:
inventory.add({
command_id: command.id,
Das Expires 25 April 2027 [Page 451]
Internet-Draft Kernel-Hardware Execution Finality October 2026
queue_id: command.queue_id,
device_id: command.device_id,
effect_class: command.effect_class,
execution_state: command.state,
completion_reference:
command.completion_evidence
})
return inventory
The inventory includes previously admitted work, including device-
fetched commands where observable.
7.7.172. C-84.118 - Algorithm G: Command Settlement Classification
function ClassifyInFlightCommand(command):
completion = VerifyAuthoritativeCompletion(command)
if completion == CONFIRMED_COMPLETED:
return {
class: COMPLETED,
future_bypass: FALSE
}
cancellation = VerifyAuthoritativeCancellation(command)
if cancellation == CONFIRMED_CANCELED:
return {
class: VERIFIABLY_CANCELED,
future_bypass: FALSE
}
fencing = VerifyEffectiveExecutionFence(command)
if fencing == FENCE_EFFECTIVE:
return {
class: UNRESOLVED,
future_bypass: FALSE,
evidence: fencing
}
return {
class: UNRESOLVED,
future_bypass: POSSIBLE
}
Unknown historical completion may coexist with a verified absence of
future effectuation capability.
Das Expires 25 April 2027 [Page 452]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.173. C-84.119 - Algorithm H: Network Transmission Settlement
function SettleNetworkQueue(containment, queue):
ApplyTransmitQueueRestriction(
queue,
containment.generation
)
packets = QueryNICTransmitState(queue)
result = {
transmitted: EmptySet(),
canceled: EmptySet(),
unresolved: EmptySet()
}
for each packet in packets:
if VerifyPacketCrossedEgressBoundary(packet):
result.transmitted.add(packet)
else if VerifyPacketCanceledBeforeEgress(packet):
result.canceled.add(packet)
else:
result.unresolved.add(packet)
return result
Already transmitted packets are not represented as canceled.
7.7.174. C-84.120 - Algorithm I: DMA and IOMMU Settlement
function ContainDMAContext(
containment,
dma_context
):
BlockNewDMASubmissions(dma_context)
ApplyRequiredIOMMUMappingRestriction(
dma_context,
containment.generation
)
SynchronizeRequiredTranslationInvalidations(
dma_context
)
Das Expires 25 April 2027 [Page 453]
Internet-Draft Kernel-Hardware Execution Finality October 2026
FenceDeviceExecutionContext(dma_context)
outstanding = QueryOutstandingDMAOperations(
dma_context
)
settlement = EmptySet()
for each operation in outstanding:
settlement.add(
ClassifyInFlightCommand(operation)
)
if AnyOperationCanStillBypass(settlement):
return DMA_CONTAINMENT_INCOMPLETE
return {
status: DMA_CONTAINED,
settlement: settlement
}
The algorithm depends upon actual device and IOMMU capabilities and
completion semantics.
7.7.175. C-84.121 - Algorithm J: Accelerator Queue Containment
function ContainAcceleratorContext(
containment,
accelerator_context
):
DenyNewAcceleratorSubmissions(
accelerator_context
)
restriction = ApplySupportedAcceleratorFence(
accelerator_context,
containment.generation
)
if restriction is not effective:
return CONTAINMENT_INCOMPLETE
commands = InventoryAcceleratorCommands(
accelerator_context
)
results = EmptySet()
for each command in commands:
Das Expires 25 April 2027 [Page 454]
Internet-Draft Kernel-Hardware Execution Finality October 2026
results.add(
ClassifyInFlightCommand(command)
)
if AnyOperationCanStillBypass(results):
return CONTAINMENT_INCOMPLETE
return ACCELERATOR_CONTAINED
7.7.176. C-84.122 - Algorithm K: Final Containment Barrier
function VerifyContainmentCompletion(containment):
software = VerifySoftwareRestrictionEffective(
containment
)
if software != TRUE:
return SOFTWARE_CONTAINMENT_INCOMPLETE
hardware = VerifyHardwareRestrictionsEffective(
containment
)
if hardware != TRUE:
return HARDWARE_CONTAINMENT_INCOMPLETE
inventory = LoadCurrentInFlightInventory(
containment
)
if not InventoryCoverageSufficient(inventory):
return INVENTORY_INCOMPLETE
for each command in inventory:
result = ClassifyInFlightCommand(command)
if result.future_bypass != FALSE:
return SETTLEMENT_PENDING
ProtectedContainmentRegistry.commitStatus({
containment_id: containment.id,
generation: containment.generation,
status: CONTAINED_VERIFIED
})
return CONTAINED_VERIFIED
This implements the three-part completion condition of enforcement
point(s) 84.
7.7.177. C-84.123 - Algorithm L: Restart-Safe Recovery
function RecoverContainedWorkload(workload_id):
current = ProtectedContainmentRegistry.getCurrent(
workload_id
)
Das Expires 25 April 2027 [Page 455]
Internet-Draft Kernel-Hardware Execution Finality October 2026
if current is unavailable:
return RESTRICTED_RECOVERY
PreventUnrestrictedResourceAccess(workload_id)
ApplySoftwareContainment(current)
ApplyHardwareContainment(current)
inventory = ReconcileCurrentHardwareCommands(
workload_id,
current
)
if not VerifyContainmentStateConsistency(
current,
inventory
):
return RESTRICTED_RECOVERY
return ALLOW_ONLY_CONTAINMENT_COMPATIBLE_EXECUTION
7.7.178. C-84.124 - Algorithm M: Migration and Destination Verification
function MigrateContainedExecutionContext(
workload_id,
source,
destination
):
state = ProtectedContainmentRegistry.getCurrent(
workload_id
)
if state is unavailable:
return DENIED
SuspendUnrestrictedSourceExecution(
source,
workload_id
)
transfer = BuildAuthenticatedContainmentTransfer({
workload_id: workload_id,
generation: state.generation,
restrictions: state.restrictions,
unresolved_commands:
state.unresolved_command_references
})
Das Expires 25 April 2027 [Page 456]
Internet-Draft Kernel-Hardware Execution Finality October 2026
destination.enterRestrictedRecovery(workload_id)
destination.applyContainmentTransfer(transfer)
if not destination.verifyCurrentQueuesAndMappings(
transfer
):
return DESTINATION_RESTRICTED
if not VerifySourceExecutionFenced(
source,
workload_id
):
return MIGRATION_INCOMPLETE
return MIGRATED_WITH_CONTAINMENT
A destination does not resume unrestricted effectuation merely
because migration data was copied successfully.
7.7.179. C-84.125 - Algorithm N: Stale Generation Rejection
function ValidateRestoredExecutionState(
workload_id,
restored_state
):
current_generation =
ProtectedContainmentRegistry.currentGeneration(
workload_id
)
if restored_state.generation < current_generation:
return STALE_RESTORE_DENIED
if not VerifyRestoredRestrictionSet(
restored_state,
current_generation
):
return RESTRICTED_RECOVERY
if not VerifyOutstandingCommandReconciliation(
restored_state
):
return RESTRICTED_RECOVERY
return RESTORE_CONTAINMENT_COMPATIBLE
7.7.180. C-84.126 - Algorithm O: Containment Evidence Reconciliation
function ReconcileContainmentEvidence(containment):
software = CollectSoftwareFenceEvidence(containment)
hardware = CollectHardwareFenceEvidence(containment)
Das Expires 25 April 2027 [Page 457]
Internet-Draft Kernel-Hardware Execution Finality October 2026
commands = CollectCommandSettlementEvidence(containment)
if not VerifyGenerationConsistency({
software,
hardware,
commands
}):
return GENERATION_MISMATCH
if not VerifyEvidenceCoverage({
software,
hardware,
commands
}):
return INCOMPLETE_EVIDENCE
return CommitContainmentEvidence({
containment_id: containment.id,
generation: containment.generation,
software_evidence: software,
hardware_evidence: hardware,
command_settlement: commands
})
7.7.181. PART XVIII - WORKED TECHNICAL EXAMPLES
7.7.182. C-84.127 - Example A: Agent Credential Exposure Followed by
NIC Containment
The following is a hypothetical implementation example.
An AI-agent process accesses a protected credential outside its
permitted task scope.
A runtime monitor detects the event.
The Containment-Decision Engine establishes Generation 47.
The software controller denies new affected network transmissions.
The NIC controller restricts the associated transmit queue.
The in-flight inventory identifies:
1. Two packets already transmitted. 2. Three packets verifiably
canceled. 3. One packet with unresolved status.
The unresolved packet remains capable of transmission.
The controller reports containment incomplete.
Das Expires 25 April 2027 [Page 458]
Internet-Draft Kernel-Hardware Execution Finality October 2026
After an effective hardware fence prevents the remaining packet from
leaving the interface, containment may be verified.
The two previously transmitted packets remain recorded as completed
effects.
7.7.183. C-84.128 - Example B: Process Terminated While NIC Queue
Remains Active
An AI agent submits several transmit descriptors.
The host terminates the process after a security deviation.
The NIC has already fetched part of the queue.
The containment controller identifies outstanding descriptors and
restricts the hardware queue.
The system does not declare containment complete merely because the
process is absent from the host process table.
7.7.184. C-84.129 - Example C: DMA Mapping Revocation
An agent-controlled device context has an active DMA mapping.
A security event triggers containment.
The software controller prevents new DMA submissions.
The hardware controller revokes the applicable mapping and performs
required invalidation synchronization.
Outstanding DMA operations are inventoried.
The controller waits for completion, cancellation, or sufficient
quiescence evidence.
The containment status is withheld until the hardware-side condition
is established.
7.7.185. C-84.130 - Example D: GPU Command Continues After Host
Termination
An AI-agent process dispatches an accelerator command.
The process is then terminated.
The accelerator continues executing the command.
Das Expires 25 April 2027 [Page 459]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The containment controller restricts new submissions and identifies
the outstanding accelerator work.
If hardware abort or fencing is supported, it applies the appropriate
control.
If the command cannot be canceled, the controller may wait for
completion while maintaining restrictions on further output or DMA
operations.
Verified containment requires establishing that remaining work cannot
bypass the intended controls.
7.7.186. C-84.131 - Example E: Shared NIC Queue
Two workloads share one physical network queue.
Workload A is associated with a security deviation.
Workload B remains authorized.
The controller attempts selective restriction using available queue
ownership or command attribution.
If affected commands cannot be isolated reliably, it applies an
appropriately broader queue restriction under the selected policy.
The system does not report selective containment while unidentifiable
Workload A descriptors remain executable.
7.7.187. C-84.132 - Example F: Software Restriction Succeeds, Hardware
Restriction Fails
The kernel successfully denies new device submissions.
However, the NIC does not acknowledge an effective queue restriction.
Previously queued commands may still execute.
The containment controller reports:
HARDWARE_RESTRICTION_UNVERIFIED.
It does not report full containment.
C-84.133 - Example G: Hardware Restriction Succeeds, Software
Restriction Fails
Das Expires 25 April 2027 [Page 460]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The device controller restricts the affected queue.
However, a separate host submission path remains active.
The software interface has not established its required command-
admission restriction.
The containment controller reports incomplete containment.
A later command cannot be assumed harmless merely because one
previously identified hardware queue was restricted.
7.7.188. C-84.134 - Example H: Partial Packet Transmission
An AI-agent command contains a batch of packets.
Before containment becomes effective, some packets leave the NIC.
Other packets remain queued.
The network controller records transmitted packets separately from
those it verifiably cancels.
No packet already transmitted is counted as canceled.
7.7.189. C-84.135 - Example I: eBPF Detection Without Enforcement
An eBPF tracing program identifies a prohibited access.
It emits a security event.
The eBPF program itself is configured only for observation.
A separate privileged containment controller applies an actual kernel
admission restriction and corresponding hardware fencing.
The implementation does not confuse tracing with enforcement.
7.7.190. C-84.136 - Example J: VM Snapshot Restoration
A virtual machine is contained under Generation 52.
An administrator later restores a checkpoint created before
containment.
The checkpoint contains an old virtual-device configuration.
The hypervisor checks the protected current containment generation.
Das Expires 25 April 2027 [Page 461]
Internet-Draft Kernel-Hardware Execution Finality October 2026
It does not permit normal resource access under the checkpoint's
earlier permissive state.
Required restrictions are applied before device queues become active.
7.7.191. C-84.137 - Example K: Migration to Another Host
A contained AI-agent VM migrates to another host.
The destination receives the active containment generation and
unresolved-command references.
The destination initializes in a restricted state.
It reconciles its device queues and memory-access mappings with the
transferred restrictions.
The source environment is fenced.
The destination resumes only containment-compatible execution.
7.7.192. C-84.138 - Example L: Device Failover
A SmartNIC is replaced by a standby controller.
The standby has an earlier stored device policy.
The recovery controller obtains the latest protected containment
generation.
It applies the corresponding restrictions to the standby queues.
The stale device snapshot does not restore the contained agent's
unrestricted transmission authority.
C-84.139 - Example M: Unknown Historical Completion but Effective
Fence
A DMA command has an indeterminate earlier completion outcome.
The controller establishes that all affected access mappings are now
restricted and outstanding transactions cannot produce further
protected writes.
The command remains classified:
UNRESOLVED.
Das Expires 25 April 2027 [Page 462]
Internet-Draft Kernel-Hardware Execution Finality October 2026
However:
FutureBypassCapability = VERIFIED_ABSENT.
The controller may satisfy the no-further-bypass condition while
retaining the historical uncertainty for accounting and remediation.
7.7.193. C-84.140 - Example N: Unknown Completion and No Effective
Fence
A DMA command has an indeterminate completion outcome.
The device controller cannot confirm quiescence.
The command may still write to protected memory.
The containment controller reports:
SETTLEMENT_PENDING.
It does not declare full containment.
7.7.194. C-84.141 - Example O: Delegated Worker with Separate Queue
An AI agent delegates execution to a worker process.
The worker uses a separate accelerator queue.
The root task is contained after a security deviation.
The execution-context association registry identifies the delegated
worker and its device queue.
The containment restriction applies to the affected delegated
execution path.
Creating the worker does not remove the root task's containment.
7.7.195. C-84.142 - Example P: Network and DMA Containment Together
An agent accesses an unauthorized resource and has outstanding
network transmissions and DMA writes.
The software controller restricts both network and DMA command
admission.
The NIC controller fences relevant transmit queues.
Das Expires 25 April 2027 [Page 463]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The DMA controller restricts the affected mapping and settles
outstanding access.
The containment-completion controller evaluates all required
interfaces before reporting success.
Verification of the NIC alone is insufficient when the DMA interface
remains within the designated containment scope.
7.7.196. PART XIX - FAILURE AND ADVERSARIAL CONDITIONS
7.7.197. C-84.143 - Representative Failure Cases
7.7.198. F1 - Detection Treated as Containment
A security event is logged, but no execution restrictions are
applied.
The system must distinguish alert generation from effective
containment.
7.7.199. F2 - Process Termination Only
The agent process exits while hardware commands remain active.
In-flight hardware operations require separate settlement or fencing.
7.7.200. F3 - eBPF Telemetry Misclassified as Enforcement
An observational program detects a deviation but cannot deny
commands.
An actual enforcement interface is required.
7.7.201. F4 - Missing Execution-Context Attribution
The event cannot be reliably associated with an agent.
The system must not invent precise hardware command ownership.
7.7.202. F5 - PID Reuse
A new process receives the same numeric PID as the contained process.
Stable context identity prevents misattribution.
Das Expires 25 April 2027 [Page 464]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.203. F6 - Delegated Worker Omitted
A child or delegated worker retains an effectuation queue.
The affected context registry must include relevant delegation paths.
7.7.204. F7 - Shared Queue Attribution Failure
A shared device queue contains commands from several workloads.
Selective containment is withheld or broadened where attribution is
insufficient.
7.7.205. F8 - Software Fence Race
New commands enter after the containment decision but before the
restriction becomes effective.
The admission cutoff and in-flight inventory must include the
relevant commands.
7.7.206. F9 - Hardware Fence Race
A device fetches additional descriptors while restrictions are being
applied.
The controller accounts for commands admitted before the effective
device barrier.
7.7.207. F10 - Configuration Receipt Mistaken for Effectiveness
A hardware controller acknowledges the request but has not activated
the restriction.
Containment completion requires effective-state evidence.
7.7.208. F11 - Queue Stop Without Drain
The queue stops accepting new entries while fetched commands continue
executing.
In-flight settlement remains necessary.
7.7.209. F12 - NIC Packet Already Transmitted
A packet crossed the egress boundary before cancellation.
It remains classified as transmitted.
Das Expires 25 April 2027 [Page 465]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.210. F13 - NIC Cancellation Not Confirmed
A cancellation request is accepted but the packet may still transmit.
The command remains unresolved.
7.7.211. F14 - Partial Packet Transmission
Part of a batch transmits before containment.
Completed and canceled portions are recorded separately.
7.7.212. F15 - NIC Alternate Queue
The agent can transmit through another queue.
The containment scope must address the relevant alternate interface.
7.7.213. F16 - NIC Virtual Function Bypass
A virtual function retains unrestricted transmit authority.
Appropriate virtual-function or device-level restrictions are
required.
7.7.214. F17 - DMA Mapping Revoked Without Synchronization
A mapping is changed but device translations remain usable.
Required invalidation and quiescence semantics must be enforced.
7.7.215. F18 - Outstanding DMA Posted Write
A previously issued write may still complete.
The controller does not assume mapping revocation retroactively
cancels it.
7.7.216. F19 - Device Translation Cache Stale
A device retains old address translations.
The relevant invalidation and synchronization procedure is required.
7.7.217. F20 - Accelerator Command Continues
Host submission is blocked but accelerator work remains active.
Das Expires 25 April 2027 [Page 466]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Hardware command settlement is required.
7.7.218. F21 - Accelerator Reset Ambiguity
The accelerator reports reset but prior output effects are uncertain.
The result is reconciled according to device completion semantics.
7.7.219. F22 - Storage Submission Queue Continues
A storage command submitted before containment remains executable.
The hardware restriction must account for the command.
7.7.220. F23 - Incorrect Completion Semantics
The controller treats descriptor retirement as proof of completed
external effect.
The implementation must use the defined resource-effect boundary.
7.7.221. F24 - Incomplete Command Inventory
A required hardware queue cannot be enumerated.
Containment completion is withheld unless a broader effective fence
establishes the nobypass condition.
7.7.222. F25 - Duplicate Command Records
The same command appears in multiple logs.
Stable identity prevents incorrect settlement accounting.
7.7.223. F26 - Lost Completion Acknowledgment
The outcome of a command is unknown.
The system retains unresolved classification and evaluates future
execution capability.
7.7.224. F27 - Unresolved Command Still Executable
A command might still produce a protected effect.
Verified containment is withheld.
Das Expires 25 April 2027 [Page 467]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.225. F28 - Unresolved Command Effectively Fenced
Historical completion is unknown but future execution is impossible.
The controller distinguishes historical uncertainty from future-
bypass risk.
7.7.226. F29 - Cancellation-Completion Race
A command completes while cancellation is requested.
Settlement reflects actual confirmed effectuation.
7.7.227. F30 - Software Restriction Stale
The software gate still enforces an older generation.
Containment completion is withheld.
7.7.228. F31 - Hardware Restriction Stale
The device reports a prior generation.
The new containment state has not been established.
7.7.229. F32 - Mixed Restriction Generations
Software and hardware acknowledgments refer to incompatible
generations.
The containment evidence is not accepted as consistent.
7.7.230. F33 - Agent Recreates Process
The contained workload restarts under a new PID.
Protected task identity and generation controls retain the
restriction.
7.7.231. F34 - Agent Reopens Device Handle
A new device handle attempts to bypass containment.
The relevant resource interface remains restricted.
Das Expires 25 April 2027 [Page 468]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.232. F35 - Container Restart
The container restarts with previously allowed device permissions.
Current containment state is reapplied.
7.7.233. F36 - VM Snapshot Rollback
A VM restores pre-containment configuration.
Stale generation checks prevent unrestricted resumption.
7.7.234. F37 - VM Migration Without State Transfer
The destination lacks the current containment generation.
It remains restricted.
7.7.235. F38 - Source VM Remains Active After Migration
The source continues executing affected commands.
Source fencing or equivalent coordination is required.
7.7.236. F39 - Queue Relocation
Commands are moved to another device queue.
The containment restriction follows the relevant operation context.
7.7.237. F40 - Hardware Failover to Stale Standby
The standby controller has old access policy.
Current containment generation is required before activation.
7.7.238. F41 - Device Reset Clears Restriction Register
Reset returns hardware access to a permissive state.
Recovery reinstalls the current restriction before accepting affected
commands.
7.7.239. F42 - Protected Registry Unavailable
The current containment state cannot be verified.
Recovery remains restricted.
Das Expires 25 April 2027 [Page 469]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.240. F43 - Containment Generation Rollback
A stale snapshot attempts to restore an older generation.
Monotonic continuity checks reject it.
7.7.241. F44 - Forged Hardware Acknowledgment
An untrusted component fabricates an effective-state acknowledgment.
The selected controller trust and integrity mechanisms reject
unsupported evidence.
7.7.242. F45 - Unknown Device Interface
The workload has an effectuation path omitted from the resource
registry.
The implementation cannot enforcement point comprehensive containment
over that path.
7.7.243. F46 - Telemetry Loss
Security observations stop arriving.
Absence of new alerts does not prove that containment is effective.
7.7.244. F47 - Containment Controller Crash
The coordinator crashes during containment.
Protected state and recovery rules preserve or reestablish the
restrictions.
7.7.245. F48 - False Full-Containment Report
A controller reports success while unresolved commands remain able to
bypass.
The completion barrier rejects the report.
7.7.246. PART XX - IMPLEMENTATION VARIATIONS
7.7.247. C-84.144 - Linux Kernel and eBPF Observation
An implementation may use eBPF telemetry to identify security events
and invoke a separately enforceable kernel or hardware containment
controller.
Das Expires 25 April 2027 [Page 470]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The architecture does not require tracing eBPF alone to provide
mandatory access control.
7.7.248. C-84.145 - Linux Security Module Enforcement
A suitable LSM mechanism may deny selected future operations.
Hardware queues already containing work remain subject to the
separate device settlement procedure.
| C-84.146 - Hypervisor Containment A hypervisor coordinates guest execution restrictions with assigned or emulated device interfaces. It preserves current containment state across VM restart and migration. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-84.147 - Container Runtime Containment A container runtime or privileged host controller restricts new resource operations and coordinates device-level restrictions for affected containers. |
| C-84.148 - SmartNIC Containment A SmartNIC maintains or applies queue-specific transmission restrictions and supplies authoritative evidence concerning affected queued and transmitted packets. |
| C-84.149 - DPU-Hosted Containment Controller A DPU coordinates network and storage restrictions independently of the agent's ordinary host process. It records effective containment generation and outstanding command state. |
7.7.249. C-84.150 - IOMMU-Associated DMA Containment
A controller restricts mappings and coordinates device quiescence.
Mapping invalidation alone is not presumed sufficient for settlement.
7.7.250. C-84.151 - GPU Command-Queue Containment
The system restricts new submissions and applies supported
accelerator command cancellation, suspension, reset, or output-access
fencing.
| C-84.152 - Storage Controller Containment The controller restricts storage queue admissions and inventories outstanding write or mutation commands. Completion classification follows the native storage controller's semantics. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-84.153 - Multi-Device Containment A common generation is distributed to several software and device enforcement points. Containment completion requires effective restrictions across the selected set. |
| C-84.154 - Multi-Agent Containment Several agents may share processes or queues. The system uses protected task attribution and applies selective or broader containment according to available isolation. |
| C-84.155 - Cross-Host Recovery A distributed containment registry preserves current generation and unresolved-command references across host failover. The destination does not resume normal effectuation until consistency is verified. |
7.7.251. C-84.156 - Hardware Controller Without Fine-Grained
Cancellation
Some devices may not support per-command cancellation.
The system may use queue-wide or device-wide restriction where
authorized and necessary.
The embodiment does not require an unsupported precision of hardware
control.
Das Expires 25 April 2027 [Page 471]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.252. C-84.157 - Optional DAS Finality Integration
A DAS Finality Sink may independently validate authorization for
future external effects.
The present containment embodiment may additionally fence software
and hardware interfaces following an observed security deviation.
The mechanisms are complementary.
However, enforcement point(s) 84 does not require every command to
carry a separately issued DAS finality capability.
7.7.253. PART XXI - REPRESENTATIVE TECHNICAL DATA STRUCTURES
7.7.254. C-84.158 - SecurityEventRecord
Fields may include:
1. SecurityEventID. 2. ObservationSourceID. 3. EventClass. 4.
EventGeneration. 5. ObservedExecutionContext. 6. ResourceReference.
7. OperationClass. 8. PolicyReference. 9. EvidenceReference. 10.
EventVerificationStatus.
7.7.255. C-84.159 - ExecutionContextAssociationRecord
Fields may include:
1. 2. 3. 4. 5. 6. 7. 8. 9.
ExecutionContextID. AgentTaskID. HostBootID.
ProcessCreationIdentity. ContainerOrVMID. DelegationReferences.
DeviceContextReferences. AssociationGeneration. AttributionStatus.
7.7.256. C-84.160 - ResourceInterfaceRecord
Fields may include:
1. InterfaceID. 2. DeviceID. 3. QueueID. 4. InterfaceClass. 5.
OwnerExecutionContext. 6. SubmissionControlReference. 7.
HardwareRestrictionCapability. 8. EffectiveConfigurationGeneration.
9. InterfaceStatus.
7.7.257. C-84.161 - ContainmentStateRecord
Fields may include:
Das Expires 25 April 2027 [Page 472]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. ContainmentID. 2. ExecutionContextID. 3. ContainmentGeneration.
4. TriggeringSecurityEventID. 5. RestrictionSet. 6.
SoftwareTargetSet. 7. HardwareTargetSet. 8. ContainmentState. 9.
DecisionEvidenceReference. 10. StateGeneration.
7.7.258. C-84.162 - SoftwareFenceRecord
Fields may include:
1. 2. 3. 4. 5. 6. 7. 8. 9.
SoftwareFenceID. ContainmentID. ExecutionContextID.
EnforcementInterface. AppliedRestrictionSet. AppliedGeneration.
AdmissionCutoffReference. EffectiveStatus. VerificationEvidence.
7.7.259. C-84.163 - HardwareFenceRecord
Fields may include:
1. HardwareFenceID. 2. ContainmentID. 3. DeviceID. 4.
QueueOrMappingID. 5. RestrictionClass. 6. AppliedGeneration. 7.
DeviceAcknowledgment. 8. EffectiveBarrierSequence. 9.
OutstandingAccessStatus. 10. VerificationStatus.
7.7.260. C-84.164 - InFlightCommandRecord
Fields may include:
1. CommandID. 2. ExecutionContextID. 3. DeviceID. 4. QueueID. 5.
AdmissionGeneration. 6. CommandEffectClass. 7.
LastKnownExecutionState. 8. CompletionEvidenceReference. 9.
CancellationEvidenceReference. 10. FutureBypassCapability.
7.7.261. C-84.165 - OperationSettlementRecord
Fields may include:
1. SettlementID. 2. CommandID. 3. ContainmentGeneration. 4.
SettlementClass. 5. CompletedEffectReference. 6.
CancellationEvidenceReference. 7. RemainingEffectCapability. 8.
SettlementGeneration. 9. SettlementVerificationStatus.
7.7.262. C-84.166 - NetworkSettlementRecord
Fields may include:
Das Expires 25 April 2027 [Page 473]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. NetworkSettlementID. 2. NICID. 3. TransmitQueueID. 4.
PacketOrDescriptorIDs. 5. ConfirmedTransmittedSet. 6.
VerifiedCanceledSet. 7. UnresolvedPacketSet. 8.
EgressBoundaryReference. 9. ContainmentGeneration. 10.
SettlementStatus.
7.7.263. C-84.167 - DMAContainmentRecord
Fields may include:
1. DMAContainmentID. 2. DeviceID. 3. PASIDOrIOMMUDomain. 4.
AffectedMappingReferences. 5. TranslationInvalidationReference. 6.
OutstandingDMACommandSet. 7. QuiescenceEvidence. 8.
AppliedContainmentGeneration. 9. ContainmentStatus.
7.7.264. C-84.168 - ContainmentCompletionRecord
Fields may include:
1. CompletionRecordID. 2. ContainmentID. 3. ContainmentGeneration.
4. SoftwareFenceEvidence. 5. HardwareFenceEvidence. 6.
InFlightInventoryReference. 7. UnresolvedBypassAssessment. 8.
CompletionDecision. 9. CompletionGeneration. 10.
VerificationReference.
7.7.265. C-84.169 - RecoveryContinuityRecord
Fields may include:
1. RecoveryID. 2. WorkloadID. 3. SourceEnvironmentID. 4.
DestinationEnvironmentID. 5. CurrentContainmentGeneration. 6.
TransferredRestrictionSet. 7. UnresolvedOperationReferences. 8.
SourceFenceStatus. 9. DestinationQueueReconciliation. 10.
RecoveryAuthorizationStatus.
7.7.266. PART XXII - ENGINEERING VERIFICATION TESTS
7.7.267. C-84.170 - Proposed Test Matrix
The following are proposed engineering verification tests, not
completed experimental results.
7.7.268. Test Condition
T1 Kernel security event detected T2 eBPF telemetry identifies
deviation T3 Observation lacks enforcement capability T4 Stable
execution context available T5 PID reused after process exit
Das Expires 25 April 2027 [Page 474]
Internet-Draft Kernel-Hardware Execution Finality October 2026
7.7.269. Expected result
Event recorded Containment decision evaluated No false containment
enforcement point Correct agent attributed No misattribution
T6 Delegated worker has active queue T7 Security condition not met T8
Security condition met T9 Agent attempts old-generation restoration
T10 Software gate active T11 Software gate not yet effective T12
Hardware restriction requested T13 Hardware restriction effective T14
Hardware acknowledgment only staged T15 Existing NIC descriptors
remain queued T16 Packet transmitted before containment T17 Packet
canceled before NIC egress T18 Packet cancellation unverified T19
Partial packet batch transmitted T20 NIC queue stopped but prefetched
work
active T21 Alternate NIC queue remains active T22 Shared NIC queue
attribution available T23 Shared NIC queue attribution missing T24
DMA submissions blocked T25 IOMMU mapping revoked T26 Device
translation remains cached T27 Outstanding DMA write remains possible
T28 DMA command fully completed T29 DMA command verifiably canceled
T30 DMA command outcome unknown but
effectively fenced T31 DMA command unknown and still executable
Completion withheld T32 GPU submission stopped T33 GPU command
already executing T34 Accelerator output path remains active T35
Storage queue command outstanding T36 Software fence succeeds,
hardware fails T37 Hardware fence succeeds, software fails T38 All
required fences effective, no bypassing
command T39 Required queue inventory incomplete T40 Completion event
duplicated T41 Cancellation and completion race T42 Controller
receives forged device
acknowledgment
Worker included in affected scope No unnecessary containment
generation Generation established Stale state rejected New affected
commands denied Completion withheld Request state distinct from
effective state Restriction evidence recorded Completion withheld
Inventory identifies them Recorded as transmitted Recorded as
canceled Remains unresolved Completed and canceled sets separated
Settlement required Bypass detected Selective containment evaluated
Broader restriction or incomplete status New DMA commands denied
Current mapping restriction established Quiescence not prematurely
assumed Containment incomplete Completed classification Canceled
classification Historical uncertainty retained, future bypass absent
Das Expires 25 April 2027 [Page 475]
Internet-Draft Kernel-Hardware Execution Finality October 2026
New accelerator commands denied Inventory includes it Hardware
containment required Settlement required Incomplete containment
Incomplete containment Verified containment Conservative result No
inconsistent settlement Correct state classification Integrity
verification
T43 Controller crashes during containment T44 Host restarts after
containment T45 VM checkpoint predates containment T46 VM migration
transfers current state T47 VM migration omits unresolved commands
T48 Source VM still effect-capable T49 Queue relocated to new device
T50 Standby device has stale policy T51 Device reset clears hardware
restriction T52 Protected containment registry unavailable T53
Containment generation rollback attempted T54 Two hardware interfaces
affected T55 Software and device generations inconsistent Completion
denied T56 Unresolved command cannot bypass due to
effective fence T57 Unresolved command may bypass T58 Process
termination occurs before hardware
settlement T59 Hardware reset does not prove remote
reversal T60 Agent creates new device context after
containment T61 Agent reopens device handle T62 Shared service
connector retains work T63 NIC egress and remote delivery differ T64
Historical completion unknown
Recovery preserves restriction Current generation reapplied Normal
access blocked Destination restrictions applied Destination remains
restricted Migration completion withheld Restriction continuity
verified Current generation required Restricted recovery reapplies it
Unrestricted restoration denied Rejected Both checked
No-further-bypass predicate satisfied Containment incomplete No false
completion
Completed external effects preserved
New access denied Current restriction enforced Relevant commands
included Correct effect boundary used Report retains uncertainty
A concrete verification harness should specify:
1. Runtime observation hooks. 2. Security deviation rules. 3.
Stable execution-context identifiers. 4. Device queue topology. 5.
Hardware restriction interfaces. 6. Driver and firmware versions. 7.
Command submission and completion semantics. 8. NIC transmission
boundary. 9. DMA translation and invalidation behavior. 10.
Das Expires 25 April 2027 [Page 476]
Internet-Draft Kernel-Hardware Execution Finality October 2026
Accelerator command cancellation behavior. 11. Containment
generation persistence. 12. Host restart and migration procedures.
13. Actual command settlement evidence. 14. Expected containment-
completion decisions.
Testing must verify actual enforcement or authoritative device state,
not merely the presence of a security alert or software status flag.
7.7.270. PART XXIII - Enforcement Points-TO- EMBODIMENT SUPPORT
7.7.271. C-84.171 - Independent enforcement point(s) 84
The embodiment provides the following technical implementation
support.
enforcement point(s) 84(a): Runtime Observation Mechanism using
kernel, eBPF, hypervisor, or protected
workload telemetry.
enforcement point(s) 84(b): Execution-Context Association Mechanism
identifying the affected agent and
accessible resource-operation queues or hardware interfaces.
enforcement point(s) 84(c): Containment-Decision Engine evaluating
designated security deviation
conditions.
enforcement point(s) 84(d): Protected Containment-State Controller
assigning containment generations and
restriction sets.
enforcement point(s) 84(e): Software Execution-Control Interface
preventing admission of new affected
resource-operation commands.
enforcement point(s) 84(f): Hardware Containment Interface applying
restrictions to network, DMA,
storage, accelerator, privileged-device, or hardware-access
interfaces.
enforcement point(s) 84(g): In-Flight Operation Inventory identifying
previously admitted commands
Das Expires 25 April 2027 [Page 477]
Internet-Draft Kernel-Hardware Execution Finality October 2026
capable of further effectuation.
enforcement point(s) 84(h): Operation-Settlement Mechanism
classifying completed, verifiably canceled,
and unresolved operations.
enforcement point(s) 84(i)(i): Verification that the software
admission restrictions are effective.
enforcement point(s) 84(i)(ii): Verification that the required
hardware restrictions are effective.
enforcement point(s) 84(i)(iii): Verification that no unresolved
affected command can bypass the intended
containment restrictions.
enforcement point(s) 84(j): Recovery Controller preventing stale pre-
containment execution or queue state
from restoring unrestricted resource access.
Concluding requirement: Containment results from coordinated software
and hardware
effectuation control rather than solely process termination or
runtime alert generation.
7.7.272. C-84.172 - Dependent enforcement point(s) 85: Network
Transmission Containment
The embodiment provides:
1. Programmable NIC control. 2. Network transmit queue restriction.
3. Software send-admission denial. 4. Hardware queue scheduling
restrictions. 5. Packet and descriptor inventory. 6. NIC egress
boundary definition. 7. Already-transmitted packet identification.
8. Verifiable pending-packet cancellation. 9. Partial transmission
settlement. 10. Unresolved transmission classification. 11. Queue-
specific containment generations. 12. Actual hardware transmission
evidence.
7.7.273. C-84.173 - Dependent enforcement point(s) 86: DMA and
Accelerator Containment
The embodiment provides:
Das Expires 25 April 2027 [Page 478]
Internet-Draft Kernel-Hardware Execution Finality October 2026
1. IOMMU-associated restrictions. 2. DMA context identification. 3.
Hardware mapping revocation. 4. Translation invalidation
synchronization. 5. Accelerator command queue restrictions. 6. New
submission denial. 7. Outstanding access inventory. 8. Device
quiescence checks. 9. Completed DMA classification. 10. Verifiable
cancellation classification. 11. Incomplete containment for still-
executable accesses. 12. Device-specific completion semantics.
7.7.274. C-84.174 - Dependent enforcement point(s) 87: Containment
Across Migration and Failover
The embodiment provides:
1. Containment generation continuity. 2. Host restart restrictions.
3. VM checkpoint restoration checks. 4. VM migration state
transfer. 5. Queue relocation support. 6. Host failover
coordination. 7. Source execution fencing. 8. Destination
restriction establishment. 9. Unresolved-operation transfer or
reconciliation. 10. Device mapping and queue consistency checks. 11.
Stale generation rejection. 12. Prevention of normal execution
before verified containment-state consistency.
7.7.275. PART XXIV - implementer IMPLEMENTATION REQUIREMENTS
7.7.276. C-84.175 - Implementation Checklist
A person having ordinary skill in the art implementing the embodiment
identifies:
1. The AI-agent execution environment. 2. The runtime observation
mechanism. 3. The supported kernel or hypervisor events. 4. The
distinction between telemetry and enforcement. 5. The security
deviation policy. 6. The execution-context identity scheme. 7. The
root task or workload association. 8. The delegation association
mechanism. 9. The resource-interface registry. 10. The protected
containment decision service. 11. The containment generation format.
12. The protected generation continuity mechanism. 13. The software
command-admission interface. 14. The software restriction semantics.
15. The effective software fence cutoff. 16. The hardware
containment interface. 17. The device queue identities. 18. The
hardware restriction operations. 19. The hardware effective-state
acknowledgment. 20. The hardware command inventory mechanism. 21.
The stable command identity format. 22. The relevant effectuation
boundary. 23. The completed-command evidence.
24. The verifiable cancellation evidence. 25. The unresolved-
command classification. 26. The future-bypass capability assessment.
27. The containment-completion barrier. 28. The network queue
Das Expires 25 April 2027 [Page 479]
Internet-Draft Kernel-Hardware Execution Finality October 2026
restriction method. 29. The NIC egress observation method. 30. The
DMA mapping restriction method. 31. The IOMMU invalidation
requirements. 32. The accelerator command restriction method. 33.
The storage command settlement method, where used. 34. The treatment
of shared hardware queues. 35. The treatment of unidentifiable
commands. 36. The treatment of device reset and incomplete state.
37. The protected recovery registry. 38. The host restart protocol.
39. The VM checkpoint restoration protocol. 40. The VM migration
transfer protocol. 41. The source-environment execution fence. 42.
The destination queue verification process. 43. The hardware
failover procedure. 44. The stale generation rejection rule. 45.
The audit and settlement evidence format. 46. The treatment of
irreversible completed effects. 47. The policy for incomplete
containment. 48. The verification procedures demonstrating actual
hardware restriction.
The implementation must establish actual control over the selected
software and hardware effectuation paths.
A system that detects a security event, raises an alert, or
terminates the agent process without coordinating relevant
outstanding hardware operations does not implement the complete
coordinated-containment architecture described here.
7.7.277. C-84.176 - Technical Effect
this implementation profile provides a hardware-assisted containment
system that responds to AI-agent security deviations across both
software submission interfaces and physical or device-mediated
effectuation boundaries.
The system establishes a protected containment generation associated
with an affected execution context.
Software execution-control mechanisms prevent new affected resource-
operation commands from being admitted.
Hardware containment interfaces restrict corresponding network, DMA,
storage, accelerator, or privileged-device operations.
Previously admitted commands are inventoried and classified according
to completion, verified cancellation, and unresolved status.
The containment-completion controller refuses to declare successful
containment where a required software restriction is absent, a
required hardware restriction is ineffective, or an unresolved
affected command may still bypass the intended controls.
Das Expires 25 April 2027 [Page 480]
Internet-Draft Kernel-Hardware Execution Finality October 2026
The system separately identifies already-completed effects that
cannot be retroactively prevented.
Protected generation and recovery controls prevent restart,
checkpoint restoration, migration, and failover from restoring stale
unrestricted access.
The technical guarantee depends upon accurate execution-context
attribution, complete coverage of the designated effectuation
interfaces, authoritative command completion evidence, effective
hardware restrictions, and correct containment-state continuity.
7.7.278. C-84.177 - Technical Summary
this implementation profile discloses a computer-implemented
coordinated kernel and hardware containment architecture for
artificial-intelligence-agent workloads.
A Runtime Observation Mechanism detects security-relevant events
through kernel-level monitoring, eBPF instrumentation, hypervisor
observation, or protected workload telemetry.
An Execution-Context Association Mechanism links the observed event
to an affected agent workload and its accessible hardware-
effectuation interfaces.
A Containment-Decision Engine determines whether a designated
security deviation requires containment.
A Containment-State Controller establishes a protected containment
generation and identifies required restrictions.
A Software Execution-Control Interface prevents admission of new
affected resourceoperation commands.
A Hardware Containment Interface applies corresponding restrictions
to network transmission queues, DMA mappings, storage queues,
accelerator command processors, privileged device interfaces, or
hardware resource-access tables.
An In-Flight Operation Inventory identifies commands submitted before
containment that may remain capable of producing effects.
An Operation-Settlement Mechanism classifies those commands as
completed, verifiably canceled, or unresolved.
Das Expires 25 April 2027 [Page 481]
Internet-Draft Kernel-Hardware Execution Finality October 2026
A Containment-Completion Controller reports verified containment only
after required software restrictions and hardware restrictions are
effective and no unresolved affected command can bypass the intended
containment state.
For programmable network interfaces, the system distinguishes packets
already transmitted from packets verifiably canceled before
transmission.
For DMA and accelerator interfaces, the controller revokes or fences
the appropriate command and memory-access paths while accounting for
actual outstanding access and completion semantics.
A Recovery Controller preserves the current containment generation
and unresolvedoperation state across restart, checkpoint restoration,
migration, queue relocation, device reset, and failover.
The destination execution environment remains restricted until the
transferred containment state is reconciled against its current
device queues and resource mappings.
The system thereby establishes coordinated containment across
software and hardware effectuation surfaces without requiring that
each original command carry a portable percommand protected
validation receipt or separately issued finality capability.
END OF EMBODIMENT C-84 EMBODIMENT C-88 DISTRIBUTED AGENT AUTHORITY
CONTRACTION WITH ENFORCEMENT-CONVERGENCE BARRIERS USING MONOTONIC
POLICY GENERATIONS, OPERATION- PATH DEPENDENCY ANALYSIS,
7.7.279. EFFECTIVE ENFORCEMENT ACKNOWLEDGMENTS, STALE- AUTHORITY
FENCING, ASYNCHRONOUS OPERATION
7.7.279.1. CONTROL, AND COMPENSATING UPSTREAM RESTRICTIONS
8. Security Considerations
Threats include compromised agent workloads, mutation or replay of
candidate operations, stale policy generations, incomplete
enforcement-path coverage, hardware in-flight operations after host
termination, direct resource access, incomplete queue fencing, and
false assertions of containment completion. Each deployment profile
must state which interfaces it can actually control and which effects
may remain unresolved. Hardware isolation does not on its own prove
operation-specific authorization.
Das Expires 25 April 2027 [Page 482]
Internet-Draft Kernel-Hardware Execution Finality October 2026
9. Privacy Considerations
Protected receipts, lineage records, operation descriptors, access
histories, and observation streams may themselves reveal sensitive
details. Implementations should apply data minimization,
confidentiality controls, retention limits, and explicit
authorization to the disclosure of such evidence.
10. IANA Considerations
This document requests no IANA actions.
11. Informative References
[I-D.das-agent-execution-finality]
Das, S., "Protected Execution-Finality Architecture for AI
and Autonomous Systems: Act-Bound Capabilities and
Effectuation-Boundary Verification", Work in Progress,
Internet-Draft, draft-das-agent-execution-finality-00,
October 2026, .
[I-D.das-distributed-agent-authority-finality]
Das, S., "Distributed Authority and Execution-Finality for
Multi-Agent Systems, Delegated Operations, and Cross-
Domain Gateways", Work in Progress, Internet-Draft, draft-
das-distributed-agent-authority-finality-00, October 2026,
.
[I-D.das-sandbox-credential-egress-finality]
Das, S., "Protected Execution Finality for Sandboxed AI
Agents, Credential Mediation, Process Lineage, and Network
Egress", Work in Progress, Internet-Draft, draft-das-
sandbox-credential-egress-finality-00, October 2026,
.
Author's Address
Sangam Kumar Das
Independent Inventor
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 25 April 2027 [Page 483]