Protected Execution-Finality Architecture for AI and Autonomous Systems: Act-Bound Capabilities and Effectuation-Boundary Verification
draft-das-agent-execution-finality-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
The 85.B2 Challenge: Does This Earlier Disclosed AI-Agent Architecture is Similar to Meta Muse/Sentinel?— Zenodo
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-agent-execution-finality-00
Network Working Group S. Das
Internet-Draft Independent Inventor
Intended status: Informational 16 October 2026
Expires: 19 April 2027
Protected Execution-Finality Architecture for AI and Autonomous Systems:
Act-Bound Capabilities and Effectuation-Boundary Verification
draft-das-agent-execution-finality-00
Abstract
This document describes a proposed protected execution-finality
architecture for artificial-intelligence agents, autonomous software
systems, confidential computing environments, and distributed
execution infrastructures. The architecture addresses a fundamental
security distinction: the ability of an AI agent or computational
process to generate, prepare, or request an operation does not
independently establish the protected authority required to make that
operation effective.
The proposed architecture separates the computation plane from
protected execution authority through mandatory operation
interception, Non-Effective State staging, machine-verifiable
Candidate Act Descriptors, a Protected Enforcement Domain (PED),
protected authorization-state management, scoped non-bearer execution
capabilities, and Finality Sink verification. A Candidate Act
remains non-effective until the applicable authority, purpose,
destination, execution scope, runtime context, policy epoch,
freshness, revocation, and other mandatory authorization predicates
have been validated. Where required, protected validation evidence
is committed before, or atomically with, capability availability.
The designated Finality Sink independently verifies the capability
against the actual operation and applicable protected state
immediately before permitting the governed consequential effect.
The architecture addresses AI-agent sandbox isolation, mandatory and
non-bypassable mediation, out-of-process permission authorities,
executable-specific access restrictions, network and API egress
enforcement, destination resolution, redirect consistency, credential
brokering, protected credential substitution, privileged connectors,
human and developer approval, runtime policy modification, multi-
agent delegation, taint and provenance-based authorization, and fail-
closed execution control.
For technical discoverability and independent architectural
examination, related publicly documented industry systems include
Meta Muse/Sentinel and NVIDIA OpenShell, NemoClaw, and the Open Agent
Das Expires 19 April 2027 [Page 1]
Internet-Draft Protected AI Execution Finality October 2026
Safety Platform/Sentry. Relevant engineering terminology includes
Muse Secure VM, isolated runtime cells, host-side permission
authority, forward proxies, surrogate credentials, just-in-time
credential insertion, eBPF/LSM-based taint propagation, controlled
network egress, executable-specific policy enforcement, developer-
approved policy changes, and hardware-assisted monitoring through
SmartNICs, data processing units, BlueField, and DOCA. These
references identify relevant public engineering contexts and
functional security objectives; they do not establish that the named
systems implement the complete architecture described here.
The principal technical distinction examined in this document
concerns the relationship between an upstream permission decision and
independently enforceable authority at the actual effectuation
boundary. The proposed execution-finality sequence includes
protected validation of a concrete Candidate Act, required protected-
state handling, validation-evidence commitment, operation-bound
capability release, and mandatory verification of that capability by
the applicable Finality Sink. The architecture distinguishes
conventional permission checking, credential isolation, model-
computation admission, and post-event monitoring or quarantine from
the separate authorization conditions required before an externally
consequential operation becomes effective.
The document further describes enforcement across network gateways,
host operating systems, credential-release interfaces, service
meshes, autonomous code-deployment systems, confidential virtual
machines, protected storage, database commitments, accelerator
fabrics, DMA/RDMA transfers, SmartNICs, DPUs, hardware Finality
Latches, and receiving-side execution boundaries. It addresses
protected state consumption, capability replay prevention, policy-
version fencing, distributed revocation, hardware attestation,
workload migration, snapshot rollback, crash-consistent recovery, and
prevention of unauthorized duplicate effects. Authorization of one
effectuation boundary does not automatically establish authority for
a distinct downstream consequence.
This individual Informational Internet-Draft presents architectural
mechanisms, enforcement points, implementation alternatives, and
security considerations for independent technical examination. It
does not specify a complete interoperable wire protocol or request
IANA allocations. Industry and product names are used solely for
technical relevance, terminology identification, and discoverability,
without implying affiliation, endorsement, copying, derivation,
infringement, patent validity, or architectural identity.
Das Expires 19 April 2027 [Page 2]
Internet-Draft Protected AI Execution Finality October 2026
Related Indian Patent Disclosures and Claimed Priority: The author
identifies Indian Application No. 202531130665, dated 23 December
2025, as an earlier related foundational disclosure, together with
Indian provisional applications 202631000572 (3 January 2026),
202631001586 (7 January 2026), and 202631002990 (12 January 2026)
concerning execution-time authorization and irreversible-boundary
enforcement. Indian Application No. 202631124028 is separately
identified as a related patent-pending application.
Related International Patent Applications and WIPO Publications: The
author identifies PCT/IB2025/058316 (Mothership; WO 2025/210622),
PCT/IB2026/053385 (ALF-PCT; WO 2026/115520), PCT/IB2026/055615 (DAS
Protocols I; WO 2026/150382), PCT/IB2026/055760 (DAS Protocols II; WO
2026/150383), PCT/IB2026/055870 (DAS Protocols III; WO 2026/150384),
PCT/IB2026/056058 (DAS Protocols IV; WO 2026/154461), PCT/
IB2026/056809 (DAS Protocols V; WO 2026/172334), and PCT/
IB2026/056941 (DAS Protocols VI; WO 2026/172336) as related technical
disclosures.
These application identifiers and publication references are provided
to facilitate independent examination of the original technical
documents and their chronology. Any claimed priority entitlement
depends upon the actual subject-matter support contained in the
corresponding earlier filing and the applicable legal requirements.
The filing chronology does not imply that every technical mechanism
described in this Internet-Draft was disclosed in every earlier
application.
Fundamental architectural principle: Computation is not authority to
act.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 April 2027.
Das Expires 19 April 2027 [Page 3]
Internet-Draft Protected AI Execution Finality October 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Status, Scope, and Interpretation . . . . . . . . . . . . . . 43
2. Industry Terminology and Technical Scope . . . . . . . . . . 43
3. Technical Discoverability and Architectural Terminology . . . 45
3.1. Product Names and Search Expressions . . . . . . . . . . 45
3.2. Published-System Vocabulary and Corresponding Technical
Examination Topics . . . . . . . . . . . . . . . . . . . 46
3.3. Five Technical Examination Questions . . . . . . . . . . 47
3.4. Specific Architectural Distinctions Requiring
Verification . . . . . . . . . . . . . . . . . . . . . . 48
3.5. Combined Technical Search Phrase . . . . . . . . . . . . 48
4. Author-Reported Indian Filing Chronology and Underlying
Concepts . . . . . . . . . . . . . . . . . . . . . . . . 49
5. Related Patent Applications and Intellectual Property
Disclosure . . . . . . . . . . . . . . . . . . . . . . . 49
5.1. Indian Applications and Earlier Disclosures . . . . . . . 50
5.2. International Patent Application Identifiers . . . . . . 50
5.3. Publication, Priority, and Scope Distinctions . . . . . . 51
5.4. IETF IPR Disclosure Process . . . . . . . . . . . . . . . 51
6. Scope and Technical Field . . . . . . . . . . . . . . . . . . 51
7. Background and Motivation . . . . . . . . . . . . . . . . . . 52
7.1. 1. Development of Autonomous Artificial-Intelligence
Execution Systems . . . . . . . . . . . . . . . . . . . 52
7.2. 2. Limitations of Conventional Authentication and
Authorization . . . . . . . . . . . . . . . . . . . . . 53
7.3. 3. Separation of Computation and Execution Authority . . 54
7.4. 4. Limitations of Sandboxing and Process Isolation
Alone . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.5. 5. Limits of Model-Level Safety and Computation
Admission . . . . . . . . . . . . . . . . . . . . . . . 55
7.6. 6. Credential Exposure and Privileged Tool Execution . . 56
7.7. 7. Delegated AI Agents and Authority Propagation . . . . 57
7.8. 8. Time-of-Check and Time-of-Use Vulnerabilities . . . . 57
Das Expires 19 April 2027 [Page 4]
Internet-Draft Protected AI Execution Finality October 2026
7.9. 9. Limitations of Post-Event Monitoring and Audit . . . 58
7.10. 10. Distributed State, Replay and Recovery Problems . . 58
7.11. 11. Confidential Computing and Cryptographic Key
Authority . . . . . . . . . . . . . . . . . . . . . . . 59
7.12. 12. Hardware and Accelerator Effectuation Boundaries . . 60
7.13. 13. Multi-Boundary and Receiving-Side Enforcement . . . 60
7.14. 14. Earlier Technical Disclosures and Related
Applications . . . . . . . . . . . . . . . . . . . . . . 61
7.15. 15. Technical Problem to Be Solved . . . . . . . . . . . 62
8. Proposed Technical Architecture . . . . . . . . . . . . . . . 63
8.1. 16. General Protected Execution-Finality Architecture . 63
8.2. 17. Candidate Act and Non-Effective State . . . . . . . 64
8.3. 18. Canonical Candidate Act Descriptor . . . . . . . . . 65
8.4. 19. Protected Enforcement Domain . . . . . . . . . . . . 66
8.5. 20. Transaction-Bound Authorization and Protected
State . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.6. 21. Protected Validation Evidence . . . . . . . . . . . 67
8.7. 22. Scoped, Non-Bearer Execution Capability . . . . . . 67
8.8. 23. Mandatory Finality Sink Verification . . . . . . . . 68
8.9. 24. Agent Sandbox and Protected Egress . . . . . . . . . 69
8.10. 25. Credential-Release and Protected Key-Use Finality . 69
8.11. 26. Confidential-VM and User-Controlled Key Authority . 70
8.12. 27. Multi-Agent Delegation . . . . . . . . . . . . . . . 71
8.13. 28. Model-Path and Downstream Effectuation Separation . 71
8.14. 29. Hardware Finality Latch and Accelerator Transfers . 72
8.15. 30. Hardware Watchdog and Revocation Interlock . . . . . 72
8.16. 31. Confidential Governance VM and Hardware-Attested
Effectuation . . . . . . . . . . . . . . . . . . . . . . 73
8.17. 32. Portable Cloud Workloads and Policy-Version
Fencing . . . . . . . . . . . . . . . . . . . . . . . . 73
8.18. 33. Atomic State, Replay Prevention and Recovery . . . . 74
8.19. 34. Multiple Finality Sinks and Receiving-Side
Enforcement . . . . . . . . . . . . . . . . . . . . . . 75
8.20. 35. Fail-Closed Handling . . . . . . . . . . . . . . . . 75
9. Architecture Summary . . . . . . . . . . . . . . . . . . . . 76
9.1. 36. General Summary . . . . . . . . . . . . . . . . . . 76
9.2. 37. Protected Agent Execution . . . . . . . . . . . . . 76
9.3. 38. Transaction-Bound Credential Control . . . . . . . . 77
9.4. 39. Protected State and Atomic Finality . . . . . . . . 77
9.5. 40. Multi-Agent Delegation . . . . . . . . . . . . . . . 78
9.6. 41. Model-Path and Effectuation-Path Separation . . . . 78
9.7. 42. Hardware-Assisted Finality . . . . . . . . . . . . . 78
9.8. 43. Confidential Governance and Key Authority . . . . . 79
9.9. 44. Monitoring and Revocation . . . . . . . . . . . . . 79
9.10. 45. Cross-Cloud Portability . . . . . . . . . . . . . . 79
9.11. 46. Independent Downstream Finality . . . . . . . . . . 80
9.12. 47. Technical Advantages . . . . . . . . . . . . . . . . 80
9.13. 48. General Inventive Principle . . . . . . . . . . . . 81
Das Expires 19 April 2027 [Page 5]
Internet-Draft Protected AI Execution Finality October 2026
10. Terminology and Definitions . . . . . . . . . . . . . . . . . 82
10.1. 1. AI-Agent Execution Environment . . . . . . . . . . . 82
10.2. 2. Proposed Operation and Candidate Act . . . . . . . . 82
10.3. 3. Externally Effective Operation . . . . . . . . . . . 82
10.4. 4. Non-Effective State (NES) . . . . . . . . . . . . . 83
10.5. 5. Mandatory Interception and Mediation . . . . . . . . 83
10.6. 6. Execution-Finality Boundary . . . . . . . . . . . . 83
10.7. 7. Finality Sink . . . . . . . . . . . . . . . . . . . 83
10.8. 8. Protected Enforcement Domain (PED) and
Cryptographically Isolated Enforcement Domain (CIED) . 84
10.9. 9. Protected Isolation from Agent Control . . . . . . . 84
10.10. 10. Non-Bypassable Governed Execution Path . . . . . . 85
10.11. 11. Finality Sink Verification . . . . . . . . . . . . 85
10.12. 12. Fail-Closed Enforcement . . . . . . . . . . . . . . 85
10.13. 13. Authority Object . . . . . . . . . . . . . . . . . 86
10.14. 14. Candidate Act Descriptor (CAD) . . . . . . . . . . 86
10.15. 15. Canonical Descriptor and Equality Verification . . 86
10.16. 16. Authority Predicate and Protected Authorization
Predicate . . . . . . . . . . . . . . . . . . . . . . . 87
10.17. 17. Authorized Purpose and Execution Scope . . . . . . 87
10.18. 18. Protected Validation Evidence . . . . . . . . . . . 88
10.19. 19. Ledger-Anchored Validation Receipt (LAVR) and Egress
LAVR . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.20. 20. Zero-Knowledge Ledger-Anchored Validation Receipt
(ZK-LAVR) . . . . . . . . . . . . . . . . . . . . . . . 88
10.21. 21. Protected Evidence Commitment and Ordering . . . . 89
10.22. 22. Scoped Execution Capability . . . . . . . . . . . . 89
10.23. 23. Non-Bearer Capability . . . . . . . . . . . . . . . 89
10.24. 24. Human Approval and Approval Artifact . . . . . . . 90
10.25. 25. Protected Policy State and Policy Epoch . . . . . . 90
10.26. 26. Runtime Execution Context . . . . . . . . . . . . . 91
10.27. 27. Nonce, Freshness, and Expiry . . . . . . . . . . . 91
10.28. 28. Revocation . . . . . . . . . . . . . . . . . . . . 91
10.29. 29. Capability Consumption . . . . . . . . . . . . . . 92
10.30. 30. Atomic Protected-State Transition . . . . . . . . . 92
10.31. 31. Formal Candidate Act State Machine . . . . . . . . 93
10.32. 32. Replay and Unauthorized Reuse . . . . . . . . . . . 93
10.33. 33. Duplicate External Effect Prevention . . . . . . . 93
10.34. 34. Crash, Retry, and Recovery . . . . . . . . . . . . 94
10.35. 35. Audit Evidence . . . . . . . . . . . . . . . . . . 94
10.36. 36. Bounded-Time and Latency-Aware Enforcement . . . . 95
10.37. 37. Algorithmic Logic Fingerprint (ALF) . . . . . . . . 95
10.38. 38. Algorithmic Intent Fingerprint (AIF) . . . . . . . 95
10.39. 39. Runtime Behavioral Descriptor (RBD) . . . . . . . . 96
10.40. 40. Tool and Workflow Graph . . . . . . . . . . . . . . 96
10.41. 41. Provenance and Taint . . . . . . . . . . . . . . . 97
10.42. 42. Untrusted Input Influence . . . . . . . . . . . . . 97
10.43. 43. Self-Mutation . . . . . . . . . . . . . . . . . . . 97
Das Expires 19 April 2027 [Page 6]
Internet-Draft Protected AI Execution Finality October 2026
10.44. 44. Delegation . . . . . . . . . . . . . . . . . . . . 98
10.45. 45. Delegation Limits . . . . . . . . . . . . . . . . . 98
10.46. 46. Candidate Deployment Act . . . . . . . . . . . . . 99
10.47. 47. Supply-Chain Authority Object . . . . . . . . . . . 99
10.48. 48. Screen-State Finality Object (SSFO) . . . . . . . . 99
10.49. 49. Network Destination, Endpoint, and Route Scope . . 100
10.50. 50. Credential Broker . . . . . . . . . . . . . . . . . 100
10.51. 51. Surrogate Credentials . . . . . . . . . . . . . . . 101
10.52. 52. Protected Credential Release . . . . . . . . . . . 101
10.53. 53. Privileged Connector . . . . . . . . . . . . . . . 101
10.54. 54. Service-Mesh and Proxy Finality Enforcement . . . . 102
10.55. 55. Protected Computation Admission . . . . . . . . . . 102
10.56. 56. Model Authorization and External Execution
Authorization . . . . . . . . . . . . . . . . . . . . . 103
10.57. 57. Candidate Commerce Act . . . . . . . . . . . . . . 103
10.58. 58. Destination Resolution and Redirect Control . . . . 103
10.59. 59. Confidential Virtual Machine (Confidential VM) . . 104
10.60. 60. Hardware Attestation . . . . . . . . . . . . . . . 104
10.61. 61. Hardware Trust Root and Virtual Trusted Platform
Module (vTPM) . . . . . . . . . . . . . . . . . . . . . 105
10.62. 62. Hardware Composite Algorithmic Logic Fingerprint
(ALF) . . . . . . . . . . . . . . . . . . . . . . . . . 105
10.63. 63. User-Controlled Root Key . . . . . . . . . . . . . 105
10.64. 64. Derived and Wrapped Keys . . . . . . . . . . . . . 106
10.65. 65. Cryptographic Authorization Commitment . . . . . . 106
10.66. 66. Hardware Freshness . . . . . . . . . . . . . . . . 107
10.67. 67. Hardware Finality Latch . . . . . . . . . . . . . . 107
10.68. 68. Candidate Fabric Transfer Act . . . . . . . . . . . 107
10.69. 69. Virtual-Machine Snapshot Rollback . . . . . . . . . 108
10.70. 70. Migration, Recovery, and Failover . . . . . . . . . 108
10.71. 71. Workload and Tenant Identity . . . . . . . . . . . 109
10.72. 72. Cloud Control Plane . . . . . . . . . . . . . . . . 109
10.73. 73. Watchdog Monitoring State . . . . . . . . . . . . . 109
10.74. 74. Quarantine . . . . . . . . . . . . . . . . . . . . 110
10.75. 75. Multiple Finality Sinks . . . . . . . . . . . . . . 110
10.76. 76. Distributed Revocation . . . . . . . . . . . . . . 111
10.77. 77. Out-of-Band Monitoring and Inline Enforcement . . . 111
10.78. 78. Cross-Component Authorization Consistency . . . . . 111
10.79. 1. Protected Enforcement Domain (PED) . . . . . . . . . 112
10.80. 2. Finality Sink (FS) . . . . . . . . . . . . . . . . . 112
10.81. 3. Candidate Act (CA) . . . . . . . . . . . . . . . . . 113
10.82. 4. Compute Plane (CP) . . . . . . . . . . . . . . . . . 113
11. Detailed Execution-Finality Workflows . . . . . . . . . . . . 114
11.1. WF-01 — Universal Protected Execution-Finality Workflow
for AI and Autonomous Computing Systems . . . . . . . . 114
11.1.1. WF-01.1 — Technical Field and Purpose . . . . . . . 114
11.1.2. WF-01.2 — Participating Technical Components . . . . 114
11.1.3. WF-01.3 — System Initialization . . . . . . . . . . 116
Das Expires 19 April 2027 [Page 7]
Internet-Draft Protected AI Execution Finality October 2026
11.1.4. WF-01.4 — Establishment of the Governed Execution
Path . . . . . . . . . . . . . . . . . . . . . . . . 117
11.1.5. WF-01.5 — Generation of a Candidate Act . . . . . . 118
11.1.6. WF-01.6 — Interception and Non-Effective Staging . . 118
11.1.7. WF-01.7 — Construction of the Candidate Act
Descriptor . . . . . . . . . . . . . . . . . . . . . 119
11.1.8. WF-01.8 — Acquisition of Applicable Authority . . . 121
11.1.9. WF-01.9 — Protected Authorization-Predicate
Validation . . . . . . . . . . . . . . . . . . . . . 122
11.1.10. WF-01.10 — Protected Authorization-State
Operation . . . . . . . . . . . . . . . . . . . . . . 123
11.1.11. WF-01.11 — Generation and Commitment of Protected
Validation Evidence . . . . . . . . . . . . . . . . . 124
11.1.12. WF-01.12 — Protected Finality Transaction . . . . . 125
11.1.13. WF-01.13 — Generation of Scoped Non-Bearer
Capability . . . . . . . . . . . . . . . . . . . . . 126
11.1.14. WF-01.14 — Transfer or Availability of the
Capability . . . . . . . . . . . . . . . . . . . . . 127
11.1.15. WF-01.15 — Reconstruction or Verification at the
Finality Sink . . . . . . . . . . . . . . . . . . . . 127
11.1.16. WF-01.16 — Capability Verification at the Finality
Sink . . . . . . . . . . . . . . . . . . . . . . . . 128
11.1.17. WF-01.17 — Protected Capability Consumption . . . . 129
11.1.18. WF-01.18 — Controlled External Effectuation . . . . 130
11.1.19. WF-01.19 — Illustrative Network-Egress
Implementation . . . . . . . . . . . . . . . . . . . 131
11.1.20. WF-01.20 — Failure, Timeout, and Denial Handling . . 132
11.1.21. WF-01.21 — Concurrency, Crash Recovery, and
Duplicate-Effect Handling . . . . . . . . . . . . . . 133
11.1.22. WF-01.22 — Alternative Structural Implementations . 133
11.1.23. WF-01.23 — Technical Result . . . . . . . . . . . . 134
11.2. WF-02 — Protected AI-Agent Sandbox Isolation, Mandatory
Interception, and Host Egress Enforcement . . . . . . . 135
11.2.1. WF-02.1 — Technical Purpose . . . . . . . . . . . . 135
11.2.2. WF-02.2 — Participating Components . . . . . . . . . 135
11.2.3. WF-02.3 — Establishment of the Sandbox Trust
Boundary . . . . . . . . . . . . . . . . . . . . . . 136
11.2.4. WF-02.4 — Identification of Governed Effectuation
Paths . . . . . . . . . . . . . . . . . . . . . . . . 137
11.2.5. WF-02.5 — Mandatory Mediation and Path-Coverage
Condition . . . . . . . . . . . . . . . . . . . . . . 138
11.2.6. WF-02.6 — Agent Operation Generation . . . . . . . . 138
11.2.7. WF-02.7 — Interception Before Effectuation . . . . . 139
11.2.8. WF-02.8 — Non-Effective Staging and Immutable Request
Representation . . . . . . . . . . . . . . . . . . . 140
11.2.9. WF-02.9 — Candidate Sandbox Egress Act Descriptor . 141
11.2.10. WF-02.10 — Retrieval of Sandbox Egress Authority
Object . . . . . . . . . . . . . . . . . . . . . . . 142
Das Expires 19 April 2027 [Page 8]
Internet-Draft Protected AI Execution Finality October 2026
11.2.11. WF-02.11 — Protected Authorization-Predicate
Validation . . . . . . . . . . . . . . . . . . . . . 143
11.2.12. WF-02.12 — Protected Grant-State and Freshness
Handling . . . . . . . . . . . . . . . . . . . . . . 144
11.2.13. WF-02.13 — Egress Validation-Evidence Commitment . . 145
11.2.14. WF-02.14 — Sandbox Egress Capability Issuance . . . 146
11.2.15. WF-02.15 — Independent Host Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 147
11.2.16. WF-02.16 — Host Shell and Executable-Specific
Enforcement . . . . . . . . . . . . . . . . . . . . . 148
11.2.17. WF-02.17 — Persistent File and Host-State Mutation
Enforcement . . . . . . . . . . . . . . . . . . . . . 149
11.2.18. WF-02.18 — Network and API Egress Enforcement . . . 150
11.2.19. WF-02.19 — Credential and Connector Boundary . . . . 150
11.2.20. WF-02.20 — Continuous Sandbox Egress and
Micro-Receipts . . . . . . . . . . . . . . . . . . . 151
11.2.21. WF-02.21 — Runtime Drift, Revocation, and Policy
Updates . . . . . . . . . . . . . . . . . . . . . . . 151
11.2.22. WF-02.22 — Failure and Containment Handling . . . . 152
11.2.23. WF-02.23 — Crash, Retry, and Capability-Reuse
Handling . . . . . . . . . . . . . . . . . . . . . . 153
11.2.24. WF-02.24 — Alternative Enforcement
Implementations . . . . . . . . . . . . . . . . . . . 153
11.2.25. WF-02.25 — Technical Verification and Test
Conditions . . . . . . . . . . . . . . . . . . . . . 154
11.2.26. WF-02.26 — Technical Effect . . . . . . . . . . . . 155
11.3. WF-03 — Network Authorization, Canonical Requests,
Destination Resolution, Redirect Consistency, and
Executable-Specific Egress Control . . . . . . . . . . 156
11.3.1. WF-03.1 — Technical Purpose . . . . . . . . . . . . 156
11.3.2. WF-03.2 — Participating Technical Components . . . . 157
11.3.3. WF-03.3 — Establishment of the Controlled Network
Path . . . . . . . . . . . . . . . . . . . . . . . . 159
11.3.4. WF-03.4 — Candidate Network Act Generation . . . . . 159
11.3.5. WF-03.5 — Capture of the Actual Request
Representation . . . . . . . . . . . . . . . . . . . 160
11.3.6. WF-03.6 — Canonical Network Operation Descriptor . . 161
11.3.7. WF-03.7 — Request-Normalization Rules . . . . . . . 162
11.3.8. WF-03.8 — Destination Classification and
Resolution . . . . . . . . . . . . . . . . . . . . . 163
11.3.9. WF-03.9 — Resolution-Dependent Authorization . . . . 164
11.3.10. WF-03.10 — DNS Rebinding and Address-Substitution
Handling . . . . . . . . . . . . . . . . . . . . . . 165
11.3.11. WF-03.11 — Executable-Specific Network
Authorization . . . . . . . . . . . . . . . . . . . . 166
11.3.12. WF-03.12 — Combined Executable and Destination
Scope . . . . . . . . . . . . . . . . . . . . . . . . 167
11.3.13. WF-03.13 — Protected Authority Validation . . . . . 168
Das Expires 19 April 2027 [Page 9]
Internet-Draft Protected AI Execution Finality October 2026
11.3.14. WF-03.14 — Protected Grant-State and Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 170
11.3.15. WF-03.15 — Scoped Network Egress Capability . . . . 171
11.3.16. WF-03.16 — Verification Immediately Before Network
Effectuation . . . . . . . . . . . . . . . . . . . . 172
11.3.17. WF-03.17 — Redirection and Multi-Hop Request
Control . . . . . . . . . . . . . . . . . . . . . . . 173
11.3.18. WF-03.18 — Connection Reuse, HTTP Multiplexing, and
Session Binding . . . . . . . . . . . . . . . . . . . 174
11.3.19. WF-03.19 — Encrypted Traffic and Application-Layer
Visibility . . . . . . . . . . . . . . . . . . . . . 175
11.3.20. WF-03.20 — Proxy, Service-Mesh, and Network-Hardware
Alternatives . . . . . . . . . . . . . . . . . . . . 176
11.3.21. WF-03.21 — Time-of-Check and Time-of-Use
Protection . . . . . . . . . . . . . . . . . . . . . 176
11.3.22. WF-03.22 — Continuous Network Egress and Rolling
Authorization . . . . . . . . . . . . . . . . . . . . 177
11.3.23. WF-03.23 — Protected Capability Consumption and Retry
Handling . . . . . . . . . . . . . . . . . . . . . . 178
11.3.24. WF-03.24 — Failure and Fail-Closed Conditions . . . 179
11.3.25. WF-03.25 — Illustrative End-to-End API Egress
Implementation . . . . . . . . . . . . . . . . . . . 180
11.3.26. WF-03.26 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 181
11.3.27. WF-03.27 — Alternative Authorization Granularity . . 183
11.3.28. WF-03.28 — Structural and Security Variations . . . 183
11.3.29. WF-03.29 — Technical Effect . . . . . . . . . . . . 184
11.4. WF-04 — Transaction-Bound Agent Authorization, Protected
Grant-State Consumption, Credential Broker, and Atomic
Credential Effectuation . . . . . . . . . . . . . . . . 185
11.4.1. WF-04.1 — Technical Purpose . . . . . . . . . . . . 185
11.4.2. WF-04.2 — Participating Components . . . . . . . . . 186
11.4.3. WF-04.3 — Credential and Authorization Separation . 188
11.4.4. WF-04.4 — Establishment of Protected Credential
Custody . . . . . . . . . . . . . . . . . . . . . . . 188
11.4.5. WF-04.5 — Non-Authoritative Credential Reference . . 189
11.4.6. WF-04.6 — Candidate Credential-Mediated Act
Generation . . . . . . . . . . . . . . . . . . . . . 190
11.4.7. WF-04.7 — Interception and Non-Effective State . . . 191
11.4.8. WF-04.8 — Canonical Operation Descriptor . . . . . . 192
11.4.9. WF-04.9 — Normalization and Actual-Operation
Correspondence . . . . . . . . . . . . . . . . . . . 194
11.4.10. WF-04.10 — Protected Authority Object . . . . . . . 194
11.4.11. WF-04.11 — Protected Authorization Predicates . . . 195
11.4.12. WF-04.12 — Protected Authorization-Grant Record . . 196
11.4.13. WF-04.13 — Protected Grant-State Reservation . . . . 197
11.4.14. WF-04.14 — Concurrency and Double-Consumption
Prevention . . . . . . . . . . . . . . . . . . . . . 198
Das Expires 19 April 2027 [Page 10]
Internet-Draft Protected AI Execution Finality October 2026
11.4.15. WF-04.15 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 199
11.4.16. WF-04.16 — Protected Credential-Finality
Transaction . . . . . . . . . . . . . . . . . . . . . 200
11.4.17. WF-04.17 — Scoped Credential-Effectuation
Capability . . . . . . . . . . . . . . . . . . . . . 201
11.4.18. WF-04.18 — Authenticated Credential-Executor
Interface . . . . . . . . . . . . . . . . . . . . . . 202
11.4.19. WF-04.19 — Independent Verification of the Actual
Operation . . . . . . . . . . . . . . . . . . . . . . 202
11.4.20. WF-04.20 — Finality Sink Verification Predicate . . 203
11.4.21. WF-04.21 — Protected Credential Selection and
Release . . . . . . . . . . . . . . . . . . . . . . . 205
11.4.22. WF-04.22 — Surrogate Credential Substitution
Variant . . . . . . . . . . . . . . . . . . . . . . . 205
11.4.23. WF-04.23 — Binding Credential Substitution to the
Exact Request . . . . . . . . . . . . . . . . . . . . 206
11.4.24. WF-04.24 — Redirect and Credential-Leakage
Prevention . . . . . . . . . . . . . . . . . . . . . 207
11.4.25. WF-04.25 — Atomic Credential Application and
Effectuation Boundary . . . . . . . . . . . . . . . . 208
11.4.26. WF-04.26 — Protected Effectuation Outcome State . . 209
11.4.27. WF-04.27 — Crash Recovery and Duplicate-Effect
Prevention . . . . . . . . . . . . . . . . . . . . . 210
11.4.28. WF-04.28 — Human Approval as a Protected
Predicate . . . . . . . . . . . . . . . . . . . . . . 211
11.4.29. WF-04.29 — Multiple Credential and Effectuation
Boundaries . . . . . . . . . . . . . . . . . . . . . 211
11.4.30. WF-04.30 — Illustrative End-to-End Enterprise API
Implementation . . . . . . . . . . . . . . . . . . . 212
11.4.31. WF-04.31 — Alternative Credential Implementations . 213
11.4.32. WF-04.32 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 214
11.4.33. WF-04.33 — Technical Result . . . . . . . . . . . . 216
11.5. WF-05 — Privileged Connector Isolation, Authenticated
Inter-Component Communication, Independent Executor
Verification, and Cross-Component Finality Consistency 217
11.5.1. WF-05.1 — Technical Purpose . . . . . . . . . . . . 217
11.5.2. WF-05.2 — Participating Technical Components . . . . 218
11.5.3. WF-05.3 — Establishment of the Agent-to-Connector
Trust Boundary . . . . . . . . . . . . . . . . . . . 220
11.5.4. WF-05.4 — Privileged Connector Security
Configuration . . . . . . . . . . . . . . . . . . . . 220
11.5.5. WF-05.5 — Authentication of Inter-Component
Communication . . . . . . . . . . . . . . . . . . . . 221
11.5.6. WF-05.6 — Connector Identity and Attestation . . . . 222
11.5.7. WF-05.7 — Candidate Connector Act Generation . . . . 223
Das Expires 19 April 2027 [Page 11]
Internet-Draft Protected AI Execution Finality October 2026
11.5.8. WF-05.8 — Mandatory Interception and Non-Effective
Staging . . . . . . . . . . . . . . . . . . . . . . . 224
11.5.9. WF-05.9 — Construction of an Operation-Specific
Canonical Descriptor . . . . . . . . . . . . . . . . 225
11.5.10. WF-05.10 — Cryptographic Authorization Commitment . 226
11.5.11. WF-05.11 — Protected Authority Validation . . . . . 227
11.5.12. WF-05.12 — Protected Grant-State Validation and
Consumption . . . . . . . . . . . . . . . . . . . . . 228
11.5.13. WF-05.13 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 229
11.5.14. WF-05.14 — Operation-Scoped Execution Capability . . 230
11.5.15. WF-05.15 — Protected Capability Delivery . . . . . . 231
11.5.16. WF-05.16 — Independent Executor Verification . . . . 232
11.5.17. WF-05.17 — Independent Verification Predicate . . . 233
11.5.18. WF-05.18 — Cross-Component Authorization
Consistency . . . . . . . . . . . . . . . . . . . . . 234
11.5.19. WF-05.19 — Mathematical Cross-Component Consistency
Condition . . . . . . . . . . . . . . . . . . . . . . 235
11.5.20. WF-05.20 — Protection Against Cross-Component State
Drift . . . . . . . . . . . . . . . . . . . . . . . . 236
11.5.21. WF-05.21 — Authorization Epoch and Revocation
Fence . . . . . . . . . . . . . . . . . . . . . . . . 237
11.5.22. WF-05.22 — Protection Against the Confused-Deputy
Condition . . . . . . . . . . . . . . . . . . . . . . 238
11.5.23. WF-05.23 — Credential and Resource Isolation . . . . 239
11.5.24. WF-05.24 — Final Operation Binding and Mutation
Prevention . . . . . . . . . . . . . . . . . . . . . 239
11.5.25. WF-05.25 — Multiple Effectuation Boundaries . . . . 240
11.5.26. WF-05.26 — Illustrative End-to-End Privileged
Connector Implementation . . . . . . . . . . . . . . 240
11.5.27. WF-05.27 — Alternative Host and Distributed
Implementations . . . . . . . . . . . . . . . . . . . 242
11.5.28. WF-05.28 — Failure, Timeout, and Recovery
Handling . . . . . . . . . . . . . . . . . . . . . . 243
11.5.29. WF-05.29 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 244
11.5.30. WF-05.30 — Technical Effect . . . . . . . . . . . . 246
11.6. WF-06 — Untrusted-Input Provenance, Process-Lineage
Influence Propagation, Taint-State Authorization
Degradation, and Protected Egress Finality . . . . . . 247
11.6.1. WF-06.1 — Technical Purpose . . . . . . . . . . . . 247
11.6.2. WF-06.2 — Participating Technical Components . . . . 248
11.6.3. WF-06.3 — Instruction Trust Hierarchy . . . . . . . 250
11.6.4. WF-06.4 — Source and Context-Unit Identification . . 250
11.6.5. WF-06.5 — Connector Boundary Receipt . . . . . . . . 252
11.6.6. WF-06.6 — Construction of the Instruction Taint
Boundary Object . . . . . . . . . . . . . . . . . . . 253
11.6.7. WF-06.7 — Influence-State Representation . . . . . . 254
Das Expires 19 April 2027 [Page 12]
Internet-Draft Protected AI Execution Finality October 2026
11.6.8. WF-06.8 — Secure Execution-Lineage Identity . . . . 255
11.6.9. WF-06.9 — Initial Influence-State Assignment . . . . 256
11.6.10. WF-06.10 — Defined Untrusted-Information Interaction
Events . . . . . . . . . . . . . . . . . . . . . . . 257
11.6.11. WF-06.11 — Protected Influence-State Update . . . . 258
11.6.12. WF-06.12 — Process Creation and Descendant
Propagation . . . . . . . . . . . . . . . . . . . . . 259
11.6.13. WF-06.13 — Process Execution and Image
Replacement . . . . . . . . . . . . . . . . . . . . . 260
11.6.14. WF-06.14 — Session, Agent, and Worker-Lineage
Propagation . . . . . . . . . . . . . . . . . . . . . 260
11.6.15. WF-06.15 — IPC, Shared Memory, and Cross-Process
Information Transfer . . . . . . . . . . . . . . . . 261
11.6.16. WF-06.16 — Protected Event-Update Ordering . . . . . 262
11.6.17. WF-06.17 — Influence-Based Authorization
Degradation . . . . . . . . . . . . . . . . . . . . . 263
11.6.18. WF-06.18 — Removal of a Broader Authorization
Lane . . . . . . . . . . . . . . . . . . . . . . . . 264
11.6.19. WF-06.19 — Candidate Act Formation Following Untrusted
Input . . . . . . . . . . . . . . . . . . . . . . . . 265
11.6.20. WF-06.20 — Candidate Act Provenance and Influence
Validation . . . . . . . . . . . . . . . . . . . . . 266
11.6.21. WF-06.21 — Instruction Taint Boundary Predicate . . 267
11.6.22. WF-06.22 — Protected Trust Elevation . . . . . . . . 268
11.6.23. WF-06.23 — Protected Revalidation and Influence-State
Reset . . . . . . . . . . . . . . . . . . . . . . . . 269
11.6.24. WF-06.24 — Binding Influence State to the Scoped
Execution Capability . . . . . . . . . . . . . . . . 269
11.6.25. WF-06.25 — Prevention of Stale Broader-Authority
Reuse . . . . . . . . . . . . . . . . . . . . . . . . 271
11.6.26. WF-06.26 — Independent Finality Sink Verification . 272
11.6.27. WF-06.27 — Concrete Process-Lineage Example . . . . 273
11.6.28. WF-06.28 — Process-Lineage Implementation
Variants . . . . . . . . . . . . . . . . . . . . . . 274
11.6.29. WF-06.29 — Completeness and Conservative
Attribution . . . . . . . . . . . . . . . . . . . . . 275
11.6.30. WF-06.30 — Crash, Restart, and Lineage-State
Continuity . . . . . . . . . . . . . . . . . . . . . 276
11.6.31. WF-06.31 — Failure and Fail-Closed Handling . . . . 276
11.6.32. WF-06.32 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 277
11.6.33. WF-06.33 — Technical Effect . . . . . . . . . . . . 279
11.7. WF-07 — Protected Browser Automation, Computer-Use
Actions, Screen-State Finality Object, and GUI Effectuation
Control . . . . . . . . . . . . . . . . . . . . . . . . 280
11.7.1. WF-07.1 — Technical Purpose . . . . . . . . . . . . 280
11.7.2. WF-07.2 — Participating Technical Components . . . . 281
Das Expires 19 April 2027 [Page 13]
Internet-Draft Protected AI Execution Finality October 2026
11.7.3. WF-07.3 — Identification of the GUI Effectuation
Boundary . . . . . . . . . . . . . . . . . . . . . . 283
11.7.4. WF-07.4 — Mandatory GUI Action Mediation . . . . . . 284
11.7.5. WF-07.5 — Candidate GUI Action Generation . . . . . 285
11.7.6. WF-07.6 — Interception and Non-Effective Staging . . 285
11.7.7. WF-07.7 — Contemporaneous Screen-State Capture . . . 286
11.7.8. WF-07.8 — Screen-State Digest . . . . . . . . . . . 288
11.7.9. WF-07.9 — Semantic Interface Measurement . . . . . . 288
11.7.10. WF-07.10 — Semantic-State Commitment . . . . . . . . 290
11.7.11. WF-07.11 — Coordinate-System Normalization . . . . . 290
11.7.12. WF-07.12 — Geometric Target Verification . . . . . . 291
11.7.13. WF-07.13 — Semantic-Geometric Equivalence . . . . . 292
11.7.14. WF-07.14 — Overlay, Z-Order, and Occlusion
Verification . . . . . . . . . . . . . . . . . . . . 293
11.7.15. WF-07.15 — Hardware-Rendered and Semantic
Coherence . . . . . . . . . . . . . . . . . . . . . . 294
11.7.16. WF-07.16 — Screen-Action Descriptor . . . . . . . . 295
11.7.17. WF-07.17 — Construction of the Screen-State Finality
Object . . . . . . . . . . . . . . . . . . . . . . . 296
11.7.18. WF-07.18 — Application Context and Target-Origin
Validation . . . . . . . . . . . . . . . . . . . . . 297
11.7.19. WF-07.19 — Purpose and Risk-Class Validation . . . . 298
11.7.20. WF-07.20 — Protected Human Authorization . . . . . . 298
11.7.21. WF-07.21 — Protected Predicate Evaluation . . . . . 299
11.7.22. WF-07.22 — Protected State and Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 300
11.7.23. WF-07.23 — Scoped Screen-Action Capability . . . . . 302
11.7.24. WF-07.24 — Immediate Pre-Dispatch Verification . . . 303
11.7.25. WF-07.25 — Time-of-Check and Time-of-Use
Protection . . . . . . . . . . . . . . . . . . . . . 304
11.7.26. WF-07.26 — Protected Capability Consumption . . . . 305
11.7.27. WF-07.27 — Browser Form Submission Example . . . . . 306
11.7.28. WF-07.28 — Payment-Confirmation and High-Risk Action
Example . . . . . . . . . . . . . . . . . . . . . . . 307
11.7.29. WF-07.29 — Terminal and Native-Application
Variations . . . . . . . . . . . . . . . . . . . . . 308
11.7.30. WF-07.30 — Failure and Fail-Closed Handling . . . . 309
11.7.31. WF-07.31 — Agent Context Correction After Denial . . 310
11.7.32. WF-07.32 — Alternative Structural Implementations . 310
11.7.33. WF-07.33 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 311
11.7.34. WF-07.34 — Technical Effect . . . . . . . . . . . . 313
11.8. WF-08 — Autonomous Commerce, Purchase Authorization,
Payment Instructions, Protected Spending Constraints, and
Commerce Finality Sink Enforcement . . . . . . . . . . 314
11.8.1. WF-08.1 — Technical Purpose . . . . . . . . . . . . 314
11.8.2. WF-08.2 — Participating Technical Components . . . . 315
Das Expires 19 April 2027 [Page 14]
Internet-Draft Protected AI Execution Finality October 2026
11.8.3. WF-08.3 — Identification of the Commercial
Effectuation Boundary . . . . . . . . . . . . . . . . 317
11.8.4. WF-08.4 — Establishment of the Governed Commerce
Path . . . . . . . . . . . . . . . . . . . . . . . . 318
11.8.5. WF-08.5 — User Mandate Formation . . . . . . . . . . 319
11.8.6. WF-08.6 — Protected Mandate Corridor . . . . . . . . 320
11.8.7. WF-08.7 — Candidate Commerce Act Generation . . . . 321
11.8.8. WF-08.8 — Mandatory Interception and Non-Effective
Staging . . . . . . . . . . . . . . . . . . . . . . . 322
11.8.9. WF-08.9 — Candidate Commerce Act Descriptor . . . . 323
11.8.10. WF-08.10 — Canonical Commercial Descriptor . . . . . 325
11.8.11. WF-08.11 — Exact Monetary Representation . . . . . . 326
11.8.12. WF-08.12 — Merchant and Counterparty Verification . 327
11.8.13. WF-08.13 — Merchant Offer and Settlement-Descriptor
Formation . . . . . . . . . . . . . . . . . . . . . . 328
11.8.14. WF-08.14 — Protected Market-Compliance Authority
Object . . . . . . . . . . . . . . . . . . . . . . . 329
11.8.15. WF-08.15 — AIF, ALF, and RBD Validation . . . . . . 330
11.8.16. WF-08.16 — Protected Commercial Authorization
Predicates . . . . . . . . . . . . . . . . . . . . . 331
11.8.17. WF-08.17 — Protected Spending-Budget State . . . . . 332
11.8.18. WF-08.18 — Atomic Budget Reservation . . . . . . . . 333
11.8.19. WF-08.19 — Spending and Authorization-State
Consistency . . . . . . . . . . . . . . . . . . . . . 334
11.8.20. WF-08.20 — Protected Commerce Validation Evidence . 334
11.8.21. WF-08.21 — Privacy-Preserving Market Validation . . 335
11.8.22. WF-08.22 — Commerce Actuation Capability . . . . . . 336
11.8.23. WF-08.23 — Commerce Finality Sink Verification . . . 337
11.8.24. WF-08.24 — Purchase, Payment Authorization, Capture,
and Settlement . . . . . . . . . . . . . . . . . . . 339
11.8.25. WF-08.25 — Controlled Payment Credential
Application . . . . . . . . . . . . . . . . . . . . . 340
11.8.26. WF-08.26 — Merchant Offer Changes and Settlement
Consistency . . . . . . . . . . . . . . . . . . . . . 341
11.8.27. WF-08.27 — Autonomous Auction and Bid Control . . . 342
11.8.28. WF-08.28 — Continuous Commerce and
Micro-Validation . . . . . . . . . . . . . . . . . . 343
11.8.29. WF-08.29 — Ranking, Recommendation, and Advertising
Effectuation . . . . . . . . . . . . . . . . . . . . 344
11.8.30. WF-08.30 — Protected Commerce Outcome-State
Machine . . . . . . . . . . . . . . . . . . . . . . . 345
11.8.31. WF-08.31 — Protected Spending Reservation Release . 346
11.8.32. WF-08.32 — Duplicate Purchase and Payment
Protection . . . . . . . . . . . . . . . . . . . . . 347
11.8.33. WF-08.33 — Concrete Autonomous Purchase Example . . 347
11.8.34. WF-08.34 — Example of Merchant-Agent Manipulation . 349
11.8.35. WF-08.35 — Failure and Fail-Closed Handling . . . . 349
11.8.36. WF-08.36 — Implementation Alternatives . . . . . . . 350
Das Expires 19 April 2027 [Page 15]
Internet-Draft Protected AI Execution Finality October 2026
11.8.37. WF-08.37 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 351
11.8.38. WF-08.38 — Technical Effect . . . . . . . . . . . . 353
11.9. WF-09 — Protected Agent Self-Modification, Policy-Digest
Transitions, Developer Approval, and Mutation-Activation
Finality . . . . . . . . . . . . . . . . . . . . . . . 354
11.9.1. WF-09.1 — Technical Purpose . . . . . . . . . . . . 354
11.9.2. WF-09.2 — Participating Technical Components . . . . 355
11.9.3. WF-09.3 — Establishment of the Mutation Trust
Boundary . . . . . . . . . . . . . . . . . . . . . . 357
11.9.4. WF-09.4 — Identification of Governed Mutation
Classes . . . . . . . . . . . . . . . . . . . . . . . 358
11.9.5. WF-09.5 — Candidate Self-Mutation Act Generation . . 359
11.9.6. WF-09.6 — Mandatory Mutation Interception . . . . . 359
11.9.7. WF-09.7 — Non-Effective Mutation Staging . . . . . . 360
11.9.8. WF-09.8 — Pre-Mutation State Measurement . . . . . . 361
11.9.9. WF-09.9 — Proposed Post-Mutation State
Measurement . . . . . . . . . . . . . . . . . . . . . 362
11.9.10. WF-09.10 — Canonical Mutation Descriptor . . . . . . 363
11.9.11. WF-09.11 — Configuration Difference and Authority
Expansion Analysis . . . . . . . . . . . . . . . . . 365
11.9.12. WF-09.12 — Self-Mutation Authority Object . . . . . 366
11.9.13. WF-09.13 — Protected Baseline and Mutation-Class
Validation . . . . . . . . . . . . . . . . . . . . . 367
11.9.14. WF-09.14 — AIF, ALF, and Runtime-Behavior
Validation . . . . . . . . . . . . . . . . . . . . . 368
11.9.15. WF-09.15 — Evaluation and Regression-Evidence
Generation . . . . . . . . . . . . . . . . . . . . . 368
11.9.16. WF-09.16 — Regression and Safety Evidence
Verification . . . . . . . . . . . . . . . . . . . . 369
11.9.17. WF-09.17 — Developer or Operator Approval . . . . . 370
11.9.18. WF-09.18 — Developer Approval as a Protected
Predicate . . . . . . . . . . . . . . . . . . . . . . 371
11.9.19. WF-09.19 — Overall Protected Mutation Validation . . 372
11.9.20. WF-09.20 — Protected Mutation-State Record . . . . . 373
11.9.21. WF-09.21 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 375
11.9.22. WF-09.22 — Scoped Self-Modification Capability . . . 376
11.9.23. WF-09.23 — Verification at the Mutation-Activation
Finality Sink . . . . . . . . . . . . . . . . . . . . 377
11.9.24. WF-09.24 — Activation Predicate . . . . . . . . . . 377
11.9.25. WF-09.25 — Atomic or Ordered Protected Activation . 379
11.9.26. WF-09.26 — Runtime Policy Publication and Reader
Consistency . . . . . . . . . . . . . . . . . . . . . 380
11.9.27. WF-09.27 — Mutation Activation and Actual Runtime
Verification . . . . . . . . . . . . . . . . . . . . 380
11.9.28. WF-09.28 — Runtime Revocation and Epoch
Advancement . . . . . . . . . . . . . . . . . . . . . 381
Das Expires 19 April 2027 [Page 16]
Internet-Draft Protected AI Execution Finality October 2026
11.9.29. WF-09.29 — Policy Mutation and Outstanding Candidate
Acts . . . . . . . . . . . . . . . . . . . . . . . . 382
11.9.30. WF-09.30 — Distributed Policy Mutation . . . . . . . 382
11.9.31. WF-09.31 — Self-Modification Versus Downstream
Effectuation . . . . . . . . . . . . . . . . . . . . 383
11.9.32. WF-09.32 — Concrete Tool-Policy Mutation Example . . 383
11.9.33. WF-09.33 — Adapter and Model-Configuration Mutation
Example . . . . . . . . . . . . . . . . . . . . . . . 385
11.9.34. WF-09.34 — Rollback, Recovery, and Failure
Handling . . . . . . . . . . . . . . . . . . . . . . 386
11.9.35. WF-09.35 — Protected Mutation Outcome State . . . . 386
11.9.36. WF-09.36 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 388
11.9.37. WF-09.37 — Alternative Technical Implementations . . 390
11.9.38. WF-09.38 — Technical Effect . . . . . . . . . . . . 391
11.10. WF-10 — Protected Multi-Agent Delegation, Parent–Child
Authority Derivation, Recursive Delegation Limits, and
Sub-Agent Acceptance Finality . . . . . . . . . . . . . 392
11.10.1. WF-10.1 — Technical Purpose . . . . . . . . . . . . 392
11.10.2. WF-10.2 — Participating Technical Components . . . 393
11.10.3. WF-10.3 — Establishment of the Parent Authority
Boundary . . . . . . . . . . . . . . . . . . . . . . 395
11.10.4. WF-10.4 — Delegation as a Separately Governed
Consequential Act . . . . . . . . . . . . . . . . . . 397
11.10.5. WF-10.5 — Candidate Delegation Act Generation . . . 397
11.10.6. WF-10.6 — Interception and Non-Effective Delegation
Staging . . . . . . . . . . . . . . . . . . . . . . . 398
11.10.7. WF-10.7 — Canonical Candidate Delegation Act
Descriptor . . . . . . . . . . . . . . . . . . . . . 399
11.10.8. WF-10.8 — Mathematical Descriptor Construction . . 400
11.10.9. WF-10.9 — Subordinate Agent Identity
Verification . . . . . . . . . . . . . . . . . . . . 401
11.10.10. WF-10.10 — Delegation Authority Object . . . . . . 402
11.10.11. WF-10.11 — Authority Attenuation Principle . . . . 404
11.10.12. WF-10.12 — Multi-Dimensional Delegated Scope . . . 404
11.10.13. WF-10.13 — Protected Context Handoff Escrow . . . . 405
11.10.14. WF-10.14 — Context Minimization and Integrity
Binding . . . . . . . . . . . . . . . . . . . . . . . 406
11.10.15. WF-10.15 — Tool-Scope Attenuation . . . . . . . . . 407
11.10.16. WF-10.16 — Credential and Memory Authority
Attenuation . . . . . . . . . . . . . . . . . . . . . 408
11.10.17. WF-10.17 — Protected Budget Allocation . . . . . . 408
11.10.18. WF-10.18 — Atomic Child Budget Reservation . . . . 409
11.10.19. WF-10.19 — Cumulative Budget Containment . . . . . 410
11.10.20. WF-10.20 — Recursive Delegation Constraint . . . . 410
11.10.21. WF-10.21 — Mathematical Recursion-Depth Control . . 411
11.10.22. WF-10.22 — Parent–Child Authority Lineage . . . . . 412
Das Expires 19 April 2027 [Page 17]
Internet-Draft Protected AI Execution Finality October 2026
11.10.23. WF-10.23 — Purpose Continuity and Prohibited
Authority Laundering . . . . . . . . . . . . . . . . 413
11.10.24. WF-10.24 — ALF, AIF, Provenance, and Runtime
Validation . . . . . . . . . . . . . . . . . . . . . 413
11.10.25. WF-10.25 — Protected Delegation Validation
Predicate . . . . . . . . . . . . . . . . . . . . . . 414
11.10.26. WF-10.26 — Constrained Delegation Decision . . . . 415
11.10.27. WF-10.27 — Protected Delegation-State Commitment . 416
11.10.28. WF-10.28 — Delegation LAVR Commitment . . . . . . . 416
11.10.29. WF-10.29 — Delegation Capability Generation . . . . 417
11.10.30. WF-10.30 — Delegation Capability Delivery . . . . . 419
11.10.31. WF-10.31 — Independent Delegation-Acceptance
Verification . . . . . . . . . . . . . . . . . . . . 419
11.10.32. WF-10.32 — Delegation Acceptance Predicate . . . . 420
11.10.33. WF-10.33 — Controlled Child-Agent Activation . . . 421
11.10.34. WF-10.34 — Separation of Delegation and Downstream
Effectuation . . . . . . . . . . . . . . . . . . . . 422
11.10.35. WF-10.35 — Recursive Child Delegation . . . . . . . 422
11.10.36. WF-10.36 — Revocation and Descendant Authority . . 423
11.10.37. WF-10.37 — Return Artifact as a Separate Candidate
Act . . . . . . . . . . . . . . . . . . . . . . . . . 423
11.10.38. WF-10.38 — Return Artifact Verification . . . . . . 424
11.10.39. WF-10.39 — Return Artifact Admission Capability . . 425
11.10.40. WF-10.40 — Concrete Parent–Child Research
Example . . . . . . . . . . . . . . . . . . . . . . . 426
11.10.41. WF-10.41 — Concrete Recursive Delegation Example . 427
11.10.42. WF-10.42 — Controlled Remote-Agent
Implementation . . . . . . . . . . . . . . . . . . . 428
11.10.43. WF-10.43 — Failure and Fail-Closed Handling . . . . 428
11.10.44. WF-10.44 — Crash, Retry, and Delegation Recovery . 429
11.10.45. WF-10.45 — Alternative Technical Implementations . 430
11.10.46. WF-10.46 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 431
11.10.47. WF-10.47 — Technical Effect . . . . . . . . . . . . 434
11.11. WF-11 — Protected Autonomous Code Changes, Artifact
Signing, Software Supply-Chain Authorization,
Agent-Generated Skill Deployment, and Progressive Release
Finality . . . . . . . . . . . . . . . . . . . . . . . 435
11.11.1. WF-11.1 — Technical Purpose . . . . . . . . . . . . 435
11.11.2. WF-11.2 — Participating Technical Components . . . 436
11.11.3. WF-11.3 — Establishment of the Software Supply-Chain
Trust Boundary . . . . . . . . . . . . . . . . . . . 438
11.11.4. WF-11.4 — Identification of Governed Release
Boundaries . . . . . . . . . . . . . . . . . . . . . 439
11.11.5. WF-11.5 — Mandatory Interception and Release-Path
Coverage . . . . . . . . . . . . . . . . . . . . . . 440
11.11.6. WF-11.6 — Generation of the Candidate Deployment
Act . . . . . . . . . . . . . . . . . . . . . . . . . 441
Das Expires 19 April 2027 [Page 18]
Internet-Draft Protected AI Execution Finality October 2026
11.11.7. WF-11.7 — Interception and Non-Effective Staging . 441
11.11.8. WF-11.8 — Construction of the Candidate Deployment
Act Descriptor . . . . . . . . . . . . . . . . . . . 442
11.11.9. WF-11.9 — Deterministic Descriptor Encoding . . . . 444
11.11.10. WF-11.10 — Acquisition of the Supply-Chain Authority
Object . . . . . . . . . . . . . . . . . . . . . . . 445
11.11.11. WF-11.11 — Authorized Development Purpose
Validation . . . . . . . . . . . . . . . . . . . . . 446
11.11.12. WF-11.12 — Approved Logic and Workflow
Validation . . . . . . . . . . . . . . . . . . . . . 446
11.11.13. WF-11.13 — Runtime Behavioral and Provenance
Validation . . . . . . . . . . . . . . . . . . . . . 447
11.11.14. WF-11.14 — Changed-File and Dependency-Scope
Validation . . . . . . . . . . . . . . . . . . . . . 448
11.11.15. WF-11.15 — Credential, Privilege, and Network-Egress
Change Validation . . . . . . . . . . . . . . . . . . 449
11.11.16. WF-11.16 — Test, Scan, Review, and Approval
Validation . . . . . . . . . . . . . . . . . . . . . 450
11.11.17. WF-11.17 — Protected Release Authorization
Predicate . . . . . . . . . . . . . . . . . . . . . . 450
11.11.18. WF-11.18 — Protected Deployment-State
Reservation . . . . . . . . . . . . . . . . . . . . . 451
11.11.19. WF-11.19 — Deployment Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 452
11.11.20. WF-11.20 — Privacy-Preserving Deployment Validation
Variant . . . . . . . . . . . . . . . . . . . . . . . 453
11.11.21. WF-11.21 — Protected Deployment-Finality
Transaction . . . . . . . . . . . . . . . . . . . . . 454
11.11.22. WF-11.22 — Scoped Release Capability Generation . . 455
11.11.23. WF-11.23 — Artifact and Commit Binding . . . . . . 456
11.11.24. WF-11.24 — Binding Source Changes to Built
Artifacts . . . . . . . . . . . . . . . . . . . . . . 457
11.11.25. WF-11.25 — Protected Artifact-Signing and Publication
Keys . . . . . . . . . . . . . . . . . . . . . . . . 457
11.11.26. WF-11.26 — Hardware-Latched Release Procedure . . . 458
11.11.27. WF-11.27 — Independent Verification at the Release
Finality Sink . . . . . . . . . . . . . . . . . . . . 459
11.11.28. WF-11.28 — Finality-Specific Release Operations . . 460
11.11.29. WF-11.29 — Agent-Generated Skill and Plugin
Deployment . . . . . . . . . . . . . . . . . . . . . 461
11.11.30. WF-11.30 — Skill Installation and Activation
Finality . . . . . . . . . . . . . . . . . . . . . . 462
11.11.31. WF-11.31 — Separation of Skill Activation from Later
Tool Execution . . . . . . . . . . . . . . . . . . . 463
11.11.32. WF-11.32 — Progressive Deployment and Stage-Specific
Authority . . . . . . . . . . . . . . . . . . . . . . 463
11.11.33. WF-11.33 — Stage-Associated Micro-LAVRs and Rollout
Capabilities . . . . . . . . . . . . . . . . . . . . 464
Das Expires 19 April 2027 [Page 19]
Internet-Draft Protected AI Execution Finality October 2026
11.11.34. WF-11.34 — Runtime Drift and Rollout
Interruption . . . . . . . . . . . . . . . . . . . . 465
11.11.35. WF-11.35 — Rollout Progression Predicate . . . . . 466
11.11.36. WF-11.36 — Protected Capability Consumption and
Duplicate-Release Prevention . . . . . . . . . . . . 467
11.11.37. WF-11.37 — Policy Updates, Revocation, and Artifact
Invalidation . . . . . . . . . . . . . . . . . . . . 468
11.11.38. WF-11.38 — Time-of-Check and Time-of-Use
Protection . . . . . . . . . . . . . . . . . . . . . 468
11.11.39. WF-11.39 — Crash, Timeout, and Deployment
Recovery . . . . . . . . . . . . . . . . . . . . . . 469
11.11.40. WF-11.40 — Illustrative Autonomous Code-Deployment
Example . . . . . . . . . . . . . . . . . . . . . . . 471
11.11.41. WF-11.41 — Illustrative Agent-Generated Skill
Example . . . . . . . . . . . . . . . . . . . . . . . 472
11.11.42. WF-11.42 — Illustrative Progressive Production
Rollout . . . . . . . . . . . . . . . . . . . . . . . 472
11.11.43. WF-11.43 — Failure and Fail-Closed Conditions . . . 473
11.11.44. WF-11.44 — Alternative Technical Implementations . 474
11.11.45. WF-11.45 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 475
11.11.46. WF-11.46 — Claim-Specific Technical Support . . . . 478
11.11.47. WF-11.47 — Technical Effect . . . . . . . . . . . . 480
11.12. WF-12 — Protected Cloud-Native Service-Mesh Execution,
Sidecar-Proxy Finality, Workload-to-Service Authorization,
Route-Bound Capabilities, and Non-Bypassable Cloud
Effectuation . . . . . . . . . . . . . . . . . . . . . 481
11.12.1. WF-12.1 — Technical Purpose . . . . . . . . . . . . 481
11.12.2. WF-12.2 — Participating Technical Components . . . 482
11.12.3. WF-12.3 — Establishment of the Cloud Workload Trust
Boundary . . . . . . . . . . . . . . . . . . . . . . 485
11.12.4. WF-12.4 — Identification of Governed Cloud
Effectuation Boundaries . . . . . . . . . . . . . . . 486
11.12.5. WF-12.5 — Mandatory Interception and Path-Coverage
Requirement . . . . . . . . . . . . . . . . . . . . . 487
11.12.6. WF-12.6 — Candidate Cloud Act Generation . . . . . 487
11.12.7. WF-12.7 — Infrastructure Interception Before
Effectuation . . . . . . . . . . . . . . . . . . . . 488
11.12.8. WF-12.8 — Non-Effective Staging and Immutable Request
Representation . . . . . . . . . . . . . . . . . . . 489
11.12.9. WF-12.9 — Workload and Service Identity
Establishment . . . . . . . . . . . . . . . . . . . . 490
11.12.10. WF-12.10 — Construction of the Candidate Cloud Act
Descriptor . . . . . . . . . . . . . . . . . . . . . 490
11.12.11. WF-12.11 — Canonical Descriptor Encoding . . . . . 492
11.12.12. WF-12.12 — Acquisition of Applicable Cloud
Authority . . . . . . . . . . . . . . . . . . . . . . 493
Das Expires 19 April 2027 [Page 20]
Internet-Draft Protected AI Execution Finality October 2026
11.12.13. WF-12.13 — Behavioral-Logic and Runtime
Validation . . . . . . . . . . . . . . . . . . . . . 493
11.12.14. WF-12.14 — Destination and Network-Route
Validation . . . . . . . . . . . . . . . . . . . . . 494
11.12.15. WF-12.15 — Protected Authorization-Predicate
Evaluation . . . . . . . . . . . . . . . . . . . . . 495
11.12.16. WF-12.16 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 496
11.12.17. WF-12.17 — Protected Cloud Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 496
11.12.18. WF-12.18 — Protected Cloud-Finality Transaction . . 498
11.12.19. WF-12.19 — Scoped Execution-Enabling Capability
Generation . . . . . . . . . . . . . . . . . . . . . 498
11.12.20. WF-12.20 — Source Workload and Service Identity
Binding . . . . . . . . . . . . . . . . . . . . . . . 500
11.12.21. WF-12.21 — Mutually Authenticated Transport-Session
Binding . . . . . . . . . . . . . . . . . . . . . . . 501
11.12.22. WF-12.22 — Capability Delivery to the Infrastructure
Finality Sink . . . . . . . . . . . . . . . . . . . . 502
11.12.23. WF-12.23 — Independent Cloud Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 502
11.12.24. WF-12.24 — Cloud Finality Verification Predicate . 503
11.12.25. WF-12.25 — Controlled Service-Mesh Effectuation . . 504
11.12.26. WF-12.26 — Service-Mesh Bypass Prevention . . . . . 505
11.12.27. WF-12.27 — Unauthorized Service Substitution . . . 505
11.12.28. WF-12.28 — Route and Policy-State Mismatch . . . . 506
11.12.29. WF-12.29 — Multi-Hop Service Invocation . . . . . . 507
11.12.30. WF-12.30 — Message-Bus and Asynchronous Workflow
Control . . . . . . . . . . . . . . . . . . . . . . . 507
11.12.31. WF-12.31 — Continuous Service Sessions and Rolling
Capabilities . . . . . . . . . . . . . . . . . . . . 508
11.12.32. WF-12.32 — Capability Consumption and Replay
Protection . . . . . . . . . . . . . . . . . . . . . 509
11.12.33. WF-12.33 — Distributed Service-Mesh State
Consistency . . . . . . . . . . . . . . . . . . . . . 510
11.12.34. WF-12.34 — Policy Updates and Revocation During
Runtime . . . . . . . . . . . . . . . . . . . . . . . 511
11.12.35. WF-12.35 — Credential and Privileged Connector
Integration . . . . . . . . . . . . . . . . . . . . . 511
11.12.36. WF-12.36 — Crash, Retry, and Incomplete Service
Effectuation . . . . . . . . . . . . . . . . . . . . 512
11.12.37. WF-12.37 — Illustrative Cloud-Native Service-Mesh
Implementation . . . . . . . . . . . . . . . . . . . 513
11.12.38. WF-12.38 — Illustrative Service Substitution
Attack . . . . . . . . . . . . . . . . . . . . . . . 514
11.12.39. WF-12.39 — Illustrative Alternative Network-Path
Attack . . . . . . . . . . . . . . . . . . . . . . . 514
11.12.40. WF-12.40 — Alternative Technical Implementations . 515
Das Expires 19 April 2027 [Page 21]
Internet-Draft Protected AI Execution Finality October 2026
11.12.41. WF-12.41 — Failure and Fail-Closed Conditions . . . 516
11.12.42. WF-12.42 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 517
11.12.43. WF-12.43 — Claim-Specific Technical Support . . . . 520
11.12.44. WF-12.44 — Technical Effect . . . . . . . . . . . . 521
11.13. WF-13 — Protected Pre-Computation Model Admission,
Algorithmic Logic Fingerprint Verification, Runtime
Behavioral Governance, Model-Loader Authorization, and
Separate Downstream Execution Finality . . . . . . . . 522
11.13.1. WF-13.1 — Technical Purpose . . . . . . . . . . . . 522
11.13.2. WF-13.2 — Participating Technical Components . . . 523
11.13.3. WF-13.3 — Establishment of the Computation Admission
Boundary . . . . . . . . . . . . . . . . . . . . . . 526
11.13.4. WF-13.4 — Identification of Governed
Computation-Start Events . . . . . . . . . . . . . . 526
11.13.5. WF-13.5 — Generation of the Candidate Computation
Admission Act . . . . . . . . . . . . . . . . . . . . 527
11.13.6. WF-13.6 — Pending Admission State . . . . . . . . . 528
11.13.7. WF-13.7 — Governed Computation-Context
Descriptor . . . . . . . . . . . . . . . . . . . . . 529
11.13.8. WF-13.8 — Canonical Computation Descriptor
Formation . . . . . . . . . . . . . . . . . . . . . . 530
11.13.9. WF-13.9 — Acquisition of Applicable Computation
Authority . . . . . . . . . . . . . . . . . . . . . . 531
11.13.10. WF-13.10 — Approved Algorithmic Logic Fingerprint
Condition . . . . . . . . . . . . . . . . . . . . . . 532
11.13.11. WF-13.11 — Composite ALF and Multi-Component Model
Configuration . . . . . . . . . . . . . . . . . . . . 533
11.13.12. WF-13.12 — Authorized Purpose and Context
Validation . . . . . . . . . . . . . . . . . . . . . 534
11.13.13. WF-13.13 — Protected Pre-Computation Authorization
Predicate . . . . . . . . . . . . . . . . . . . . . . 534
11.13.14. WF-13.14 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 535
11.13.15. WF-13.15 — Computation-Admission Validation
Evidence . . . . . . . . . . . . . . . . . . . . . . 536
11.13.16. WF-13.16 — Computation-Start Authorization
Artifact . . . . . . . . . . . . . . . . . . . . . . 537
11.13.17. WF-13.17 — Model and Workflow Measurement
Binding . . . . . . . . . . . . . . . . . . . . . . . 538
11.13.18. WF-13.18 — Independent Computation-Admission
Verification . . . . . . . . . . . . . . . . . . . . 539
11.13.19. WF-13.19 — Computation Admission Verification
Predicate . . . . . . . . . . . . . . . . . . . . . . 540
11.13.20. WF-13.20 — Protected Model-Loader Admission . . . . 541
11.13.21. WF-13.21 — Model Loader Verification Sequence . . . 541
11.13.22. WF-13.22 — Accelerator and Model-State
Activation . . . . . . . . . . . . . . . . . . . . . 542
Das Expires 19 April 2027 [Page 22]
Internet-Draft Protected AI Execution Finality October 2026
11.13.23. WF-13.23 — Runtime Behavioral Descriptor
Formation . . . . . . . . . . . . . . . . . . . . . . 543
11.13.24. WF-13.24 — Runtime Behavioral Drift and Continued
Governance . . . . . . . . . . . . . . . . . . . . . 544
11.13.25. WF-13.25 — Pre-Computation and Runtime Authorization
Separation . . . . . . . . . . . . . . . . . . . . . 544
11.13.26. WF-13.26 — Separate Downstream Execution
Authority . . . . . . . . . . . . . . . . . . . . . . 545
11.13.27. WF-13.27 — Downstream Finality Verification
Sequence . . . . . . . . . . . . . . . . . . . . . . 546
11.13.28. WF-13.28 — Example: Approved Model, Unauthorized Tool
Operation . . . . . . . . . . . . . . . . . . . . . . 547
11.13.29. WF-13.29 — Example: Unauthorized Adapter
Substitution . . . . . . . . . . . . . . . . . . . . 547
11.13.30. WF-13.30 — Example: Retrieval-Policy
Modification . . . . . . . . . . . . . . . . . . . . 548
11.13.31. WF-13.31 — Authorization Refresh and Policy Epoch
Changes . . . . . . . . . . . . . . . . . . . . . . . 548
11.13.32. WF-13.32 — Replay and Unauthorized Reuse
Prevention . . . . . . . . . . . . . . . . . . . . . 549
11.13.33. WF-13.33 — Crash, Restart, and Recovery . . . . . . 550
11.13.34. WF-13.34 — Alternative Structural
Implementations . . . . . . . . . . . . . . . . . . . 550
11.13.35. WF-13.35 — Failure and Fail-Closed Conditions . . . 551
11.13.36. WF-13.36 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 553
11.13.37. WF-13.37 — Claim-Specific Technical Support . . . . 555
11.13.38. WF-13.38 — Technical Effect . . . . . . . . . . . . 556
11.14. WF-14 — Protected Model-Path and Downstream
Effectuation-Path Dual Authorization, Inference-to-Act
Context Binding, Streaming Output Control, Multi-Sink
Classification, and Remote Finality Verification . . . 558
11.14.1. WF-14.1 — Technical Purpose . . . . . . . . . . . . 558
11.14.2. WF-14.2 — Participating Technical Components . . . 559
11.14.3. WF-14.3 — Establishment of Two Governed Authorization
Boundaries . . . . . . . . . . . . . . . . . . . . . 562
11.14.4. WF-14.4 — Model-Path Trust Boundary . . . . . . . . 563
11.14.5. WF-14.5 — Downstream Effectuation Trust Boundary . 564
11.14.6. WF-14.6 — Generation of the Proposed Inference
Request . . . . . . . . . . . . . . . . . . . . . . . 565
11.14.7. WF-14.7 — Protected Computation-Admission
Validation . . . . . . . . . . . . . . . . . . . . . 565
11.14.8. WF-14.8 — Protected Computation-Admission Record . 566
11.14.9. WF-14.9 — Admission Record Authentication and
Binding . . . . . . . . . . . . . . . . . . . . . . . 567
11.14.10. WF-14.10 — Controlled Model Computation . . . . . . 568
11.14.11. WF-14.11 — Identification of the Consequential
Operation . . . . . . . . . . . . . . . . . . . . . . 569
Das Expires 19 April 2027 [Page 23]
Internet-Draft Protected AI Execution Finality October 2026
11.14.12. WF-14.12 — Non-Effective State for the Derived
Candidate Act . . . . . . . . . . . . . . . . . . . . 570
11.14.13. WF-14.13 — Inference-to-Act Context Binding . . . . 570
11.14.14. WF-14.14 — Downstream Candidate Act Descriptor . . 571
11.14.15. WF-14.15 — Canonical Operation Descriptor . . . . . 573
11.14.16. WF-14.16 — Acquisition of Operation-Specific
Execution Authority . . . . . . . . . . . . . . . . . 573
11.14.17. WF-14.17 — Protected Downstream Authorization
Predicates . . . . . . . . . . . . . . . . . . . . . 574
11.14.18. WF-14.18 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 575
11.14.19. WF-14.19 — Protected Operation-Specific Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 576
11.14.20. WF-14.20 — Protected Downstream Finality
Transaction . . . . . . . . . . . . . . . . . . . . . 577
11.14.21. WF-14.21 — Operation-Specific Execution
Capability . . . . . . . . . . . . . . . . . . . . . 577
11.14.22. WF-14.22 — Independent Downstream Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 578
11.14.23. WF-14.23 — Downstream Finality Verification
Predicate . . . . . . . . . . . . . . . . . . . . . . 579
11.14.24. WF-14.24 — Distinction Between Model Authorization
and Effectuation Authorization . . . . . . . . . . . 580
11.14.25. WF-14.25 — Revocation of Model Access . . . . . . . 580
11.14.26. WF-14.26 — Already Generated and Buffered Candidate
Acts . . . . . . . . . . . . . . . . . . . . . . . . 581
11.14.27. WF-14.27 — Model-Path Interruption and
External-Effect Timing . . . . . . . . . . . . . . . 582
11.14.28. WF-14.28 — Streaming Model Output and Partial-Action
Classification . . . . . . . . . . . . . . . . . . . 582
11.14.29. WF-14.29 — Non-Effective Buffering of Streaming
Operations . . . . . . . . . . . . . . . . . . . . . 583
11.14.30. WF-14.30 — Completed or Bounded Candidate Act
Formation . . . . . . . . . . . . . . . . . . . . . . 584
11.14.31. WF-14.31 — Partial-Action Finality Predicate . . . 585
11.14.32. WF-14.32 — Multi-Sink Effectuation
Classification . . . . . . . . . . . . . . . . . . . 585
11.14.33. WF-14.33 — Multi-Sink Authorization Independence . 586
11.14.34. WF-14.34 — Receiving-Side and Remote Finality
Sink . . . . . . . . . . . . . . . . . . . . . . . . 587
11.14.35. WF-14.35 — Remote Actual-Operation
Reconstruction . . . . . . . . . . . . . . . . . . . 588
11.14.36. WF-14.36 — Receiving-Side Verification Predicate . 589
11.14.37. WF-14.37 — Illustrative End-to-End AI-Agent
Transaction . . . . . . . . . . . . . . . . . . . . . 590
11.14.38. WF-14.38 — Illustrative Model-Interruption
Attack . . . . . . . . . . . . . . . . . . . . . . . 591
11.14.39. WF-14.39 — Illustrative Multi-Sink Workflow . . . . 591
Das Expires 19 April 2027 [Page 24]
Internet-Draft Protected AI Execution Finality October 2026
11.14.40. WF-14.40 — Protected Capability Consumption and
Replay Prevention . . . . . . . . . . . . . . . . . . 592
11.14.41. WF-14.41 — Crash, Retry, and Recovery . . . . . . . 593
11.14.42. WF-14.42 — Alternative Structural
Implementations . . . . . . . . . . . . . . . . . . . 594
11.14.43. WF-14.43 — Failure and Fail-Closed Conditions . . . 595
11.14.44. WF-14.44 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 596
11.14.45. WF-14.45 — Claim-Specific Technical Support . . . . 599
11.14.46. WF-14.46 — Technical Effect . . . . . . . . . . . . 601
11.15. WF-15 — Protected Cross-Domain AI-Fabric Transfer
Finality, GPU/TPU/NPU Accelerator Isolation,
Hardware-Latched DMA and Interconnect Admission, Continuous
Tensor-Stream Authorization, Hardware Freshness, and
Line-Rate Capability Verification . . . . . . . . . . . 602
11.15.1. WF-15.1 — Technical Purpose . . . . . . . . . . . . 602
11.15.2. WF-15.2 — Participating Technical Components . . . 604
11.15.3. WF-15.3 — Establishment of the Accelerator and Fabric
Trust Boundaries . . . . . . . . . . . . . . . . . . 606
11.15.4. WF-15.4 — Hardware-Assisted Enforcement
Configuration . . . . . . . . . . . . . . . . . . . . 607
11.15.5. WF-15.5 — Definition of the Governed Transfer
Effect . . . . . . . . . . . . . . . . . . . . . . . 608
11.15.6. WF-15.6 — Generation of the Candidate Fabric Transfer
Act . . . . . . . . . . . . . . . . . . . . . . . . . 609
11.15.7. WF-15.7 — Interception and Non-Effective Transfer
Staging . . . . . . . . . . . . . . . . . . . . . . . 610
11.15.8. WF-15.8 — Candidate Fabric Transfer Act Descriptor
Formation . . . . . . . . . . . . . . . . . . . . . . 611
11.15.9. WF-15.9 — Canonical Transfer Descriptor Encoding . 612
11.15.10. WF-15.10 — Acquisition of Cross-Domain Fabric
Authority . . . . . . . . . . . . . . . . . . . . . . 613
11.15.11. WF-15.11 — Source-Domain Authority Validation . . . 614
11.15.12. WF-15.12 — Destination-Domain Authority
Validation . . . . . . . . . . . . . . . . . . . . . 615
11.15.13. WF-15.13 — Computation-Data Classification . . . . 615
11.15.14. WF-15.14 — Approved Workload Graph and Transfer
Envelope . . . . . . . . . . . . . . . . . . . . . . 616
11.15.15. WF-15.15 — Fabric Route and Switch Validation . . . 617
11.15.16. WF-15.16 — Protected Fabric Authorization
Predicate . . . . . . . . . . . . . . . . . . . . . . 618
11.15.17. WF-15.17 — Protected Fabric Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 619
11.15.18. WF-15.18 — Fabric Transfer Validation Evidence . . 619
11.15.19. WF-15.19 — Protected Fabric Finality Transaction . 621
11.15.20. WF-15.20 — Scoped Fabric Transfer Capability . . . 621
11.15.21. WF-15.21 — Illustrative Cryptographic Capability
Representation . . . . . . . . . . . . . . . . . . . 623
Das Expires 19 April 2027 [Page 25]
Internet-Draft Protected AI Execution Finality October 2026
11.15.22. WF-15.22 — Independent Verification at the Fabric
Finality Sink . . . . . . . . . . . . . . . . . . . . 624
11.15.23. WF-15.23 — Fabric Finality Verification
Predicate . . . . . . . . . . . . . . . . . . . . . . 625
11.15.24. WF-15.24 — Hardware-Latched Transfer Admission . . 626
11.15.25. WF-15.25 — Hardware-Latch Activation Sequence . . . 627
11.15.26. WF-15.26 — Continuous Tensor and Memory-Transfer
Validation . . . . . . . . . . . . . . . . . . . . . 627
11.15.27. WF-15.27 — Rolling Transfer Authorization State . . 628
11.15.28. WF-15.28 — Continuous Transfer Monitoring and Drift
Detection . . . . . . . . . . . . . . . . . . . . . . 629
11.15.29. WF-15.29 — Transfer-Size and Workload-Graph Anomaly
Handling . . . . . . . . . . . . . . . . . . . . . . 630
11.15.30. WF-15.30 — Hardware-Freshness Binding . . . . . . . 631
11.15.31. WF-15.31 — Hardware-Freshness Verification
Procedure . . . . . . . . . . . . . . . . . . . . . . 632
11.15.32. WF-15.32 — Prevention of Replay Across Device
Reset . . . . . . . . . . . . . . . . . . . . . . . . 633
11.15.33. WF-15.33 — Cold-Path Authority Validation . . . . . 633
11.15.34. WF-15.34 — Bounded-Time Local Fabric
Verification . . . . . . . . . . . . . . . . . . . . 634
11.15.35. WF-15.35 — Local Capability-Table Implementation . 635
11.15.36. WF-15.36 — Time-of-Check and Time-of-Use
Protection . . . . . . . . . . . . . . . . . . . . . 636
11.15.37. WF-15.37 — Protected Capability Consumption . . . . 636
11.15.38. WF-15.38 — Crash, Timeout, Reset, and Recovery . . 637
11.15.39. WF-15.39 — Illustrative GPU-to-GPU Tensor
Transfer . . . . . . . . . . . . . . . . . . . . . . 638
11.15.40. WF-15.40 — Illustrative DMA-Bypass Attempt . . . . 639
11.15.41. WF-15.41 — Illustrative Continuous Tensor-Stream
Rollout . . . . . . . . . . . . . . . . . . . . . . . 640
11.15.42. WF-15.42 — Illustrative Hardware Freshness and Replay
Attack . . . . . . . . . . . . . . . . . . . . . . . 640
11.15.43. WF-15.43 — Alternative Technical Implementations . 641
11.15.44. WF-15.44 — Failure and Fail-Closed Conditions . . . 642
11.15.45. WF-15.45 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 644
11.15.46. WF-15.46 — Claim-Specific Technical Support . . . . 647
11.15.47. WF-15.47 — Technical Effect . . . . . . . . . . . . 648
11.16. WF-16 — Distributed Hardware-Watchdog Execution Interlock,
Protected Monitoring-State Attestation, Multi-Sink
Revocation Fencing, Fail-Closed Monitoring Failure, and
Effectuation-State-Preserving Quarantine . . . . . . . 650
11.16.1. WF-16.1 — Technical Purpose . . . . . . . . . . . . 650
11.16.2. WF-16.2 — Participating Technical Components . . . 651
11.16.3. WF-16.3 — Establishment of the Monitoring and
Execution Trust Boundaries . . . . . . . . . . . . . 654
11.16.4. WF-16.4 — Definition of Out-of-Band Monitoring . . 655
Das Expires 19 April 2027 [Page 26]
Internet-Draft Protected AI Execution Finality October 2026
11.16.5. WF-16.5 — Identification of Governed Consequential
Boundaries . . . . . . . . . . . . . . . . . . . . . 656
11.16.6. WF-16.6 — Mandatory Effectuation-Path Coverage . . 657
11.16.7. WF-16.7 — Monitoring-State Collection . . . . . . . 658
11.16.8. WF-16.8 — Protected Monitoring-State Record . . . . 659
11.16.9. WF-16.9 — Monitoring-State Versioning . . . . . . . 660
11.16.10. WF-16.10 — Hardware-Attested Monitoring State . . . 661
11.16.11. WF-16.11 — Protected Attestation Verification . . . 662
11.16.12. WF-16.12 — Candidate Act Generation . . . . . . . . 662
11.16.13. WF-16.13 — Interception and Non-Effective
Staging . . . . . . . . . . . . . . . . . . . . . . . 663
11.16.14. WF-16.14 — Candidate Act Descriptor Formation . . . 664
11.16.15. WF-16.15 — Canonical Descriptor and Monitoring-State
Binding . . . . . . . . . . . . . . . . . . . . . . . 665
11.16.16. WF-16.16 — Acquisition of Operation-Specific
Authority . . . . . . . . . . . . . . . . . . . . . . 666
11.16.17. WF-16.17 — Combined Monitoring and Operation
Authorization . . . . . . . . . . . . . . . . . . . . 666
11.16.18. WF-16.18 — Protected Authorization-State
Transition . . . . . . . . . . . . . . . . . . . . . 667
11.16.19. WF-16.19 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 668
11.16.20. WF-16.20 — Protected Watchdog-Finality
Transaction . . . . . . . . . . . . . . . . . . . . . 669
11.16.21. WF-16.21 — Monitoring-State-Bound Execution
Capability . . . . . . . . . . . . . . . . . . . . . 670
11.16.22. WF-16.22 — Multiple Independently Enforceable
Finality Sinks . . . . . . . . . . . . . . . . . . . 671
11.16.23. WF-16.23 — Independent Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 672
11.16.24. WF-16.24 — Monitoring-State-Aware Sink Predicate . 673
11.16.25. WF-16.25 — Watchdog-Detected Violation . . . . . . 674
11.16.26. WF-16.26 — Protected Revocation-Fence
Advancement . . . . . . . . . . . . . . . . . . . . . 674
11.16.27. WF-16.27 — Enforcement of Superseded Monitoring
Versions . . . . . . . . . . . . . . . . . . . . . . 675
11.16.28. WF-16.28 — Prevention Despite Continued or
Interrupted Model Access . . . . . . . . . . . . . . 676
11.16.29. WF-16.29 — Monitoring-State Unavailability . . . . 677
11.16.30. WF-16.30 — Stale and Inconsistent Monitoring-State
Handling . . . . . . . . . . . . . . . . . . . . . . 677
11.16.31. WF-16.31 — Protected Monitoring Recovery . . . . . 678
11.16.32. WF-16.32 — Quarantine Initiation . . . . . . . . . 679
11.16.33. WF-16.33 — Quarantine Enforcement . . . . . . . . . 680
11.16.34. WF-16.34 — Preservation of Effectuation State During
Quarantine . . . . . . . . . . . . . . . . . . . . . 681
11.16.35. WF-16.35 — No Automatic Rollback or Replay
Authority . . . . . . . . . . . . . . . . . . . . . . 682
Das Expires 19 April 2027 [Page 27]
Internet-Draft Protected AI Execution Finality October 2026
11.16.36. WF-16.36 — Cross-Component Monitoring-State
Consistency . . . . . . . . . . . . . . . . . . . . . 683
11.16.37. WF-16.37 — Illustrative Network and Storage Dual-Sink
System . . . . . . . . . . . . . . . . . . . . . . . 684
11.16.38. WF-16.38 — Illustrative Watchdog-to-Finality
Revocation . . . . . . . . . . . . . . . . . . . . . 685
11.16.39. WF-16.39 — Illustrative Continued-Inference
Scenario . . . . . . . . . . . . . . . . . . . . . . 685
11.16.40. WF-16.40 — Illustrative Watchdog Failure . . . . . 686
11.16.41. WF-16.41 — Illustrative Quarantine After Possible
External Effect . . . . . . . . . . . . . . . . . . . 686
11.16.42. WF-16.42 — Alternative Technical Implementations . 687
11.16.43. WF-16.43 — Failure and Fail-Closed Conditions . . . 688
11.16.44. WF-16.44 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 689
11.16.45. WF-16.45 — Claim-Specific Technical Support . . . . 692
11.16.46. WF-16.46 — Technical Effect . . . . . . . . . . . . 694
11.17. WF-17 — Protected Confidential Virtual-Machine Execution,
Hardware-Rooted Composite ALF Validation, Workload-to-Act
Authorization, Privacy-Preserving Validation, Tenant-Bound
Capabilities, and Snapshot-Rollback-Resistant Finality 695
11.17.1. WF-17.1 — Technical Purpose . . . . . . . . . . . . 695
11.17.2. WF-17.2 — Participating Technical Components . . . 697
11.17.3. WF-17.3 — Establishment of the Confidential-Computing
Trust Boundary . . . . . . . . . . . . . . . . . . . 699
11.17.4. WF-17.4 — Isolation of Protected Execution
Authority . . . . . . . . . . . . . . . . . . . . . . 700
11.17.5. WF-17.5 — Identification of Governed Effectuation
Paths . . . . . . . . . . . . . . . . . . . . . . . . 701
11.17.6. WF-17.6 — Execution-Context Measurement . . . . . . 702
11.17.7. WF-17.7 — Execution-Context Measurement Record . . 702
11.17.8. WF-17.8 — Hardware-Rooted Composite ALF
Formation . . . . . . . . . . . . . . . . . . . . . . 703
11.17.9. WF-17.9 — Composite ALF Cryptographic
Representation . . . . . . . . . . . . . . . . . . . 704
11.17.10. WF-17.10 — Authentication of the Measurement
Source . . . . . . . . . . . . . . . . . . . . . . . 705
11.17.11. WF-17.11 — Runtime-Used Configuration
Verification . . . . . . . . . . . . . . . . . . . . 706
11.17.12. WF-17.12 — Distinguishing Launch Attestation from
Runtime Integrity . . . . . . . . . . . . . . . . . . 707
11.17.13. WF-17.13 — Candidate Act Generation . . . . . . . . 708
11.17.14. WF-17.14 — Interception and Non-Effective
Staging . . . . . . . . . . . . . . . . . . . . . . . 708
11.17.15. WF-17.15 — Candidate Act Descriptor Construction . 709
11.17.16. WF-17.16 — Canonical Candidate Act Descriptor . . . 710
11.17.17. WF-17.17 — Acquisition of Applicable Authority . . 711
Das Expires 19 April 2027 [Page 28]
Internet-Draft Protected AI Execution Finality October 2026
11.17.18. WF-17.18 — Protected Runtime and Operation
Authorization . . . . . . . . . . . . . . . . . . . . 712
11.17.19. WF-17.19 — Protected Authorization-State
Operations . . . . . . . . . . . . . . . . . . . . . 713
11.17.20. WF-17.20 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 713
11.17.21. WF-17.21 — Protected Confidential-Workload Finality
Transaction . . . . . . . . . . . . . . . . . . . . . 714
11.17.22. WF-17.22 — Scoped Non-Bearer Execution
Capability . . . . . . . . . . . . . . . . . . . . . 715
11.17.23. WF-17.23 — Privacy-Preserving Protected Validation
Evidence . . . . . . . . . . . . . . . . . . . . . . 717
11.17.24. WF-17.24 — Confidential Validation and Finality Sink
Independence . . . . . . . . . . . . . . . . . . . . 718
11.17.25. WF-17.25 — Independent Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 719
11.17.26. WF-17.26 — Finality Sink Verification Predicate . . 719
11.17.27. WF-17.27 — Tenant and Destination Scope Binding . . 720
11.17.28. WF-17.28 — Cross-Tenant Authority Isolation . . . . 721
11.17.29. WF-17.29 — Virtual-Machine Snapshot Rollback
Threat . . . . . . . . . . . . . . . . . . . . . . . 722
11.17.30. WF-17.30 — Protected Rollback-Resistant State . . . 723
11.17.31. WF-17.31 — Capability Consumption Before and During
Effectuation . . . . . . . . . . . . . . . . . . . . 724
11.17.32. WF-17.32 — Virtual-Machine Snapshot Restoration . . 724
11.17.33. WF-17.33 — Snapshot-Replay Rejection . . . . . . . 725
11.17.34. WF-17.34 — VM Migration and Workload Replacement . 726
11.17.35. WF-17.35 — Revocation and Policy-Epoch Changes . . 726
11.17.36. WF-17.36 — Time-of-Check and Time-of-Use
Protection . . . . . . . . . . . . . . . . . . . . . 727
11.17.37. WF-17.37 — Illustrative Confidential AI-Agent API
Operation . . . . . . . . . . . . . . . . . . . . . . 728
11.17.38. WF-17.38 — Illustrative Composite ALF Mismatch . . 729
11.17.39. WF-17.39 — Illustrative Cross-Tenant Destination
Substitution . . . . . . . . . . . . . . . . . . . . 730
11.17.40. WF-17.40 — Illustrative Snapshot-Rollback Attack . 730
11.17.41. WF-17.41 — Illustrative Privacy-Preserving
Validation . . . . . . . . . . . . . . . . . . . . . 731
11.17.42. WF-17.42 — Failure, Crash, and Recovery Handling . 731
11.17.43. WF-17.43 — Alternative Technical Implementations . 732
11.17.44. WF-17.44 — Failure and Fail-Closed Conditions . . . 733
11.17.45. WF-17.45 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 735
11.17.46. WF-17.46 — Claim-Specific Technical Support . . . . 738
11.17.47. WF-17.47 — Technical Effect . . . . . . . . . . . . 740
Das Expires 19 April 2027 [Page 29]
Internet-Draft Protected AI Execution Finality October 2026
11.18. WF-18 — Confidential Governance Virtual Machine,
Hardware-Rooted Attestation, Protected Governance-Key
Isolation, Authenticated Fabric Capability Delivery, and
Hardware-Enforced SmartNIC Finality . . . . . . . . . . 741
11.18.1. WF-18.1 — Technical Purpose . . . . . . . . . . . . 741
11.18.2. WF-18.2 — Participating Technical Components . . . 742
11.18.3. WF-18.3 — Establishment of the AI
Compute-to-Governance Trust Boundary . . . . . . . . 745
11.18.4. WF-18.4 — Establishment of the Confidential
Governance VM . . . . . . . . . . . . . . . . . . . . 746
11.18.5. WF-18.5 — Governance-Node Identity Registration . . 747
11.18.6. WF-18.6 — Hardware Finality Gate Attestation Object
Formation . . . . . . . . . . . . . . . . . . . . . . 747
11.18.7. WF-18.7 — Hardware Trust-Root Verification . . . . 749
11.18.8. WF-18.8 — Governance Attestation State
Registration . . . . . . . . . . . . . . . . . . . . 750
11.18.9. WF-18.9 — Protected Governance-Key Isolation . . . 750
11.18.10. WF-18.10 — Protected Capability Issuance Key Use . 751
11.18.11. WF-18.11 — Candidate Act Generation . . . . . . . . 752
11.18.12. WF-18.12 — Non-Effective Staging . . . . . . . . . 752
11.18.13. WF-18.13 — Candidate Act Descriptor Formation . . . 753
11.18.14. WF-18.14 — Canonical Candidate Act
Representation . . . . . . . . . . . . . . . . . . . 754
11.18.15. WF-18.15 — Candidate Act Authority Validation . . . 755
11.18.16. WF-18.16 — Combined Attestation and Act-Specific
Authorization Predicate . . . . . . . . . . . . . . . 756
11.18.17. WF-18.17 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 757
11.18.18. WF-18.18 — Protected Validation Evidence . . . . . 757
11.18.19. WF-18.19 — Scoped Execution-Capability
Generation . . . . . . . . . . . . . . . . . . . . . 758
11.18.20. WF-18.20 — Cryptographically Authenticated
Capability . . . . . . . . . . . . . . . . . . . . . 759
11.18.21. WF-18.21 — Authenticated Fabric-Management Capability
Delivery . . . . . . . . . . . . . . . . . . . . . . 760
11.18.22. WF-18.22 — Capability Delivery and Actual-Operation
Consistency . . . . . . . . . . . . . . . . . . . . . 761
11.18.23. WF-18.23 — Hardware Finality Sink Verification . . 762
11.18.24. WF-18.24 — Hardware Finality Verification
Predicate . . . . . . . . . . . . . . . . . . . . . . 763
11.18.25. WF-18.25 — Hardware-Enforced Transmission
Interlock . . . . . . . . . . . . . . . . . . . . . . 764
11.18.26. WF-18.26 — Confidential Governance Measurement
Change . . . . . . . . . . . . . . . . . . . . . . . 764
11.18.27. WF-18.27 — Attestation Revalidation . . . . . . . . 765
11.18.28. WF-18.28 — Hardware-Freshness Binding . . . . . . . 766
11.18.29. WF-18.29 — Snapshot, Reset, and Hardware Replay
Resistance . . . . . . . . . . . . . . . . . . . . . 767
Das Expires 19 April 2027 [Page 30]
Internet-Draft Protected AI Execution Finality October 2026
11.18.30. WF-18.30 — Capability Consumption and Hardware
State . . . . . . . . . . . . . . . . . . . . . . . . 767
11.18.31. WF-18.31 — Attestation-State Revocation at
Distributed Controllers . . . . . . . . . . . . . . . 768
11.18.32. WF-18.32 — Illustrative Confidential Governance VM
and SmartNIC Deployment . . . . . . . . . . . . . . . 769
11.18.33. WF-18.33 — Illustrative Compromised AI Compute
Process . . . . . . . . . . . . . . . . . . . . . . . 770
11.18.34. WF-18.34 — Illustrative Governance Firmware
Measurement Change . . . . . . . . . . . . . . . . . 771
11.18.35. WF-18.35 — Illustrative Hardware-Freshness Replay
Attack . . . . . . . . . . . . . . . . . . . . . . . 771
11.18.36. WF-18.36 — Crash, Reset, and Recovery . . . . . . . 772
11.18.37. WF-18.37 — Alternative Technical Implementations . 773
11.18.38. WF-18.38 — Failure and Fail-Closed Conditions . . . 773
11.18.39. WF-18.39 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 775
11.18.40. WF-18.40 — Claim-Specific Technical Support . . . . 778
11.18.41. WF-18.41 — Technical Effect . . . . . . . . . . . . 779
11.19. WF-19 — User-Controlled Confidential Virtual Machine,
Root-Key Sovereignty, Attested Derived-Key Release,
Separate Data-Access and Execution Authority,
Privacy-Preserving Finality Evidence, and
Rollback-Resistant Recovery . . . . . . . . . . . . . . 780
11.19.1. WF-19.1 — Technical Purpose . . . . . . . . . . . . 781
11.19.2. WF-19.2 — Participating Technical Components . . . 782
11.19.3. WF-19.3 — Separation of Confidentiality and Execution
Authority . . . . . . . . . . . . . . . . . . . . . . 784
11.19.4. WF-19.4 — Confidential Virtual-Machine
Establishment . . . . . . . . . . . . . . . . . . . . 785
11.19.5. WF-19.5 — User-Controlled Root-Key Establishment . 786
11.19.6. WF-19.6 — Protected User-Data Encryption . . . . . 786
11.19.7. WF-19.7 — Hardware-Rooted Confidential-VM
Attestation . . . . . . . . . . . . . . . . . . . . . 787
11.19.8. WF-19.8 — Verification of the Confidential-VM
Measurement . . . . . . . . . . . . . . . . . . . . . 788
11.19.9. WF-19.9 — User-Authorized Data-Access Scope . . . . 789
11.19.10. WF-19.10 — Protected Data-Access Authorization
Predicate . . . . . . . . . . . . . . . . . . . . . . 790
11.19.11. WF-19.11 — Derived, Wrapped, or Session-Limited Key
Release . . . . . . . . . . . . . . . . . . . . . . . 790
11.19.12. WF-19.12 — Illustrative Protected Key Derivation . 791
11.19.13. WF-19.13 — Bounded Cryptographic Data Access . . . 792
11.19.14. WF-19.14 — Dual Authorization for Data Access and
External Effect . . . . . . . . . . . . . . . . . . . 793
11.19.15. WF-19.15 — Candidate Act Generation . . . . . . . . 793
11.19.16. WF-19.16 — Interception and Non-Effective State . . 794
11.19.17. WF-19.17 — Canonical Candidate Act Descriptor . . . 795
Das Expires 19 April 2027 [Page 31]
Internet-Draft Protected AI Execution Finality October 2026
11.19.18. WF-19.18 — Operation-Specific Authority
Validation . . . . . . . . . . . . . . . . . . . . . 796
11.19.19. WF-19.19 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 797
11.19.20. WF-19.20 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 797
11.19.21. WF-19.21 — Protected Execution-Finality
Transaction . . . . . . . . . . . . . . . . . . . . . 798
11.19.22. WF-19.22 — Cryptographically Bound Operation-Specific
Capability . . . . . . . . . . . . . . . . . . . . . 799
11.19.23. WF-19.23 — Independent Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 800
11.19.24. WF-19.24 — Operation and Attestation Substitution
Protection . . . . . . . . . . . . . . . . . . . . . 801
11.19.25. WF-19.25 — Privacy-Preserving Execution Evidence . 801
11.19.26. WF-19.26 — Distinction Between Authorization Evidence
and Completion Evidence . . . . . . . . . . . . . . . 802
11.19.27. WF-19.27 — Root-Key Confidentiality During Evidence
Verification . . . . . . . . . . . . . . . . . . . . 803
11.19.28. WF-19.28 — Separate Key-Access and Execution
Revocation . . . . . . . . . . . . . . . . . . . . . 804
11.19.29. WF-19.29 — Confidential-VM Backup and Snapshot
Protection . . . . . . . . . . . . . . . . . . . . . 804
11.19.30. WF-19.30 — Attested Recovery of the Confidential
VM . . . . . . . . . . . . . . . . . . . . . . . . . 805
11.19.31. WF-19.31 — Protected Capability-Consumption State
Continuity . . . . . . . . . . . . . . . . . . . . . 806
11.19.32. WF-19.32 — Snapshot-Rollback Replay Protection . . 807
11.19.33. WF-19.33 — User Root-Key Continuity During
Recovery . . . . . . . . . . . . . . . . . . . . . . 807
11.19.34. WF-19.34 — Illustrative Confidential AI-Agent
Document Processing . . . . . . . . . . . . . . . . . 808
11.19.35. WF-19.35 — Illustrative Connected-Service Credential
Operation . . . . . . . . . . . . . . . . . . . . . . 809
11.19.36. WF-19.36 — Illustrative VM Snapshot Recovery . . . 809
11.19.37. WF-19.37 — Failure, Crash, and Recovery Handling . 810
11.19.38. WF-19.38 — Alternative Technical Implementations . 811
11.19.39. WF-19.39 — Failure and Fail-Closed Conditions . . . 812
11.19.40. WF-19.40 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 813
11.19.41. WF-19.41 — Claim-Specific Technical Support . . . . 816
11.19.42. WF-19.42 — Technical Effect . . . . . . . . . . . . 818
11.20. WF-20 — Protected Derived-Key and Wrapped-Key Enablement,
Attestation-Bound Key Release, Cryptographic Key-Use
Finality, Separation of Data Access from Execution
Authority, and Hardware-Enforced Credential and
Effectuation Control . . . . . . . . . . . . . . . . . 819
11.20.1. WF-20.1 — Technical Purpose . . . . . . . . . . . . 819
Das Expires 19 April 2027 [Page 32]
Internet-Draft Protected AI Execution Finality October 2026
11.20.2. WF-20.2 — Participating Technical Components . . . 821
11.20.3. WF-20.3 — Separation of Root-Key Control and AI
Computation . . . . . . . . . . . . . . . . . . . . . 823
11.20.4. WF-20.4 — Root-Key and Derived-Key Distinction . . 824
11.20.5. WF-20.5 — User-Authorized Key Scope . . . . . . . . 825
11.20.6. WF-20.6 — Hardware Attestation Before Key
Enablement . . . . . . . . . . . . . . . . . . . . . 826
11.20.7. WF-20.7 — Protected Key-Enablement Decision . . . . 827
11.20.8. WF-20.8 — Derived-Key Release . . . . . . . . . . . 828
11.20.9. WF-20.9 — Wrapped-Key Enablement . . . . . . . . . 829
11.20.10. WF-20.10 — Session-Limited Key Enablement . . . . . 830
11.20.11. WF-20.11 — Bounded Cryptographic Operation Without
Key Export . . . . . . . . . . . . . . . . . . . . . 830
11.20.12. WF-20.12 — Cryptographic Access Is Not External
Execution Authority . . . . . . . . . . . . . . . . . 831
11.20.13. WF-20.13 — Candidate Cryptographic Operation . . . 832
11.20.14. WF-20.14 — Interception of the Consequential
Operation . . . . . . . . . . . . . . . . . . . . . . 832
11.20.15. WF-20.15 — Candidate Act Descriptor Formation . . . 833
11.20.16. WF-20.16 — Canonical Candidate Act
Representation . . . . . . . . . . . . . . . . . . . 834
11.20.17. WF-20.17 — Protected Operation-Specific
Authority . . . . . . . . . . . . . . . . . . . . . . 835
11.20.18. WF-20.18 — Operation-Specific Authorization
Predicate . . . . . . . . . . . . . . . . . . . . . . 836
11.20.19. WF-20.19 — Protected State Transition . . . . . . . 837
11.20.20. WF-20.20 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 837
11.20.21. WF-20.21 — Operation-Specific Execution
Capability . . . . . . . . . . . . . . . . . . . . . 838
11.20.22. WF-20.22 — Protected Key-Use Finality Sink . . . . 839
11.20.23. WF-20.23 — External Effectuation Finality Sink . . 840
11.20.24. WF-20.24 — Relationship Between Key-Use and External
Finality . . . . . . . . . . . . . . . . . . . . . . 840
11.20.25. WF-20.25 — Governance-Key Isolation . . . . . . . . 841
11.20.26. WF-20.26 — Attestation-Dependent Governance Key
Use . . . . . . . . . . . . . . . . . . . . . . . . . 841
11.20.27. WF-20.27 — Hardware-Freshness Binding . . . . . . . 842
11.20.28. WF-20.28 — Revocation of Data-Access Keys . . . . . 843
11.20.29. WF-20.29 — Revocation of External Execution
Authority . . . . . . . . . . . . . . . . . . . . . . 843
11.20.30. WF-20.30 — Key Rotation and Version Continuity . . 844
11.20.31. WF-20.31 — Snapshot and Backup Recovery . . . . . . 845
11.20.32. WF-20.32 — Key-State and Capability-State
Separation . . . . . . . . . . . . . . . . . . . . . 845
11.20.33. WF-20.33 — Crash Between Authorization and
Effectuation . . . . . . . . . . . . . . . . . . . . 846
Das Expires 19 April 2027 [Page 33]
Internet-Draft Protected AI Execution Finality October 2026
11.20.34. WF-20.34 — Illustrative User-Controlled Encrypted
Data Access . . . . . . . . . . . . . . . . . . . . . 847
11.20.35. WF-20.35 — Illustrative Protected Credential
Broker . . . . . . . . . . . . . . . . . . . . . . . 848
11.20.36. WF-20.36 — Illustrative Signing-Key Finality . . . 848
11.20.37. WF-20.37 — Illustrative Snapshot Replay . . . . . . 849
11.20.38. WF-20.38 — Alternative Technical Implementations . 850
11.20.39. WF-20.39 — Failure and Fail-Closed Conditions . . . 850
11.20.40. WF-20.40 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 852
11.20.41. WF-20.41 — Claim-Specific Technical Support . . . . 854
11.20.42. WF-20.42 — Technical Effect . . . . . . . . . . . . 856
11.21. WF-21 — Hardware Finality Latch, NIC/SmartNIC/DPU
Enforcement, Protected DMA and Network Admission,
Capability-Dependent Hardware Effectuation, and Fail-Closed
Revocation . . . . . . . . . . . . . . . . . . . . . . 858
11.21.1. WF-21.1 — Technical Purpose . . . . . . . . . . . . 858
11.21.2. WF-21.2 — Participating Technical Components . . . 859
11.21.3. WF-21.3 — Definition of Hardware Finality Latch . . 861
11.21.4. WF-21.4 — Distinction Among PED, Finality Gate,
Finality Sink, and Latch . . . . . . . . . . . . . . 862
11.21.5. WF-21.5 — Establishment of the Hardware Enforcement
Boundary . . . . . . . . . . . . . . . . . . . . . . 863
11.21.6. WF-21.6 — Candidate Act Generation . . . . . . . . 864
11.21.7. WF-21.7 — Interception and Non-Effective State . . 864
11.21.8. WF-21.8 — Candidate Act Descriptor Formation . . . 865
11.21.9. WF-21.9 — Canonical Hardware Operation
Representation . . . . . . . . . . . . . . . . . . . 866
11.21.10. WF-21.10 — Acquisition of Hardware Effectuation
Authority . . . . . . . . . . . . . . . . . . . . . . 867
11.21.11. WF-21.11 — Protected Authorization Predicate . . . 868
11.21.12. WF-21.12 — Protected Authorization-State
Transition . . . . . . . . . . . . . . . . . . . . . 869
11.21.13. WF-21.13 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 869
11.21.14. WF-21.14 — Scoped Hardware Execution Capability . . 870
11.21.15. WF-21.15 — Illustrative Capability
Authentication . . . . . . . . . . . . . . . . . . . 871
11.21.16. WF-21.16 — Capability Delivery to the Hardware
Controller . . . . . . . . . . . . . . . . . . . . . 872
11.21.17. WF-21.17 — Hardware Finality Sink Verification . . 873
11.21.18. WF-21.18 — Hardware Effectuation Predicate . . . . 874
11.21.19. WF-21.19 — Hardware Finality Latch State Machine . 874
11.21.20. WF-21.20 — Hardware-Latched DMA and Accelerator
Transfer . . . . . . . . . . . . . . . . . . . . . . 875
11.21.21. WF-21.21 — SmartNIC and DPU Network Forwarding . . 876
11.21.22. WF-21.22 — Hardware Fast-Path Verification . . . . 877
Das Expires 19 April 2027 [Page 34]
Internet-Draft Protected AI Execution Finality October 2026
11.21.23. WF-21.23 — Continuous and Windowed Transfer
Authorization . . . . . . . . . . . . . . . . . . . . 878
11.21.24. WF-21.24 — Hardware-Freshness and Replay
Protection . . . . . . . . . . . . . . . . . . . . . 878
11.21.25. WF-21.25 — Optional Confidential Governance Node . 879
11.21.26. WF-21.26 — Optional Hardware Watchdog Interlock . . 880
11.21.27. WF-21.27 — Protected Revocation Fence . . . . . . . 880
11.21.28. WF-21.28 — Protection Against Hardware Bypass
Paths . . . . . . . . . . . . . . . . . . . . . . . . 881
11.21.29. WF-21.29 — Independent Hardware Effectuation
Verification . . . . . . . . . . . . . . . . . . . . 882
11.21.30. WF-21.30 — Capability Consumption and
Concurrency . . . . . . . . . . . . . . . . . . . . . 882
11.21.31. WF-21.31 — Device Reset and Recovery . . . . . . . 883
11.21.32. WF-21.32 — Partial Transfer and Indeterminate
Completion . . . . . . . . . . . . . . . . . . . . . 883
11.21.33. WF-21.33 — Illustrative NIC Egress Finality . . . . 884
11.21.34. WF-21.34 — Illustrative GPU DMA Finality . . . . . 885
11.21.35. WF-21.35 — Illustrative DPU Watchdog and Revocation
Interlock . . . . . . . . . . . . . . . . . . . . . . 885
11.21.36. WF-21.36 — Illustrative Confidential Governance VM
and SmartNIC . . . . . . . . . . . . . . . . . . . . 886
11.21.37. WF-21.37 — Failure and Fail-Closed Conditions . . . 886
11.21.38. WF-21.38 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 888
11.21.39. WF-21.39 — Claim-Specific Technical Coverage . . . 890
11.21.40. WF-21.40 — Technical Effect . . . . . . . . . . . . 892
11.22. WF-22 — Portable Cloud-VM Agent Authority, Cross-Cloud
Workload Identity, Runtime Policy-Epoch Synchronization,
Hardware-Supervised Egress, Migration and Snapshot
Protection, and Downstream Effectuation Finality . . . 893
11.22.1. WF-22.1 — Technical Purpose . . . . . . . . . . . . 893
11.22.2. WF-22.2 — Participating Technical Components . . . 895
11.22.3. WF-22.3 — Supported Portable AI Execution
Substrates . . . . . . . . . . . . . . . . . . . . . 898
11.22.4. WF-22.4 — Separation of Workload Deployment and
Execution Authority . . . . . . . . . . . . . . . . . 898
11.22.5. WF-22.5 — Establishment of the Workload Identity . 899
11.22.6. WF-22.6 — Execution-Context Measurement . . . . . . 900
11.22.7. WF-22.7 — Authentication of the Execution-Context
Measurement . . . . . . . . . . . . . . . . . . . . . 901
11.22.8. WF-22.8 — Protected Workload Authority
Registration . . . . . . . . . . . . . . . . . . . . 902
11.22.9. WF-22.9 — Candidate Act Generation . . . . . . . . 903
11.22.10. WF-22.10 — Interception and Non-Effective
Staging . . . . . . . . . . . . . . . . . . . . . . . 903
11.22.11. WF-22.11 — Candidate Act Descriptor . . . . . . . . 904
Das Expires 19 April 2027 [Page 35]
Internet-Draft Protected AI Execution Finality October 2026
11.22.12. WF-22.12 — Canonical Candidate Act
Representation . . . . . . . . . . . . . . . . . . . 905
11.22.13. WF-22.13 — Protected Operation Authorization . . . 906
11.22.14. WF-22.14 — Protected Authorization Predicate . . . 907
11.22.15. WF-22.15 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 907
11.22.16. WF-22.16 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 908
11.22.17. WF-22.17 — Scoped Portable-Workload Execution
Capability . . . . . . . . . . . . . . . . . . . . . 909
11.22.18. WF-22.18 — Illustrative Cryptographic Capability . 910
11.22.19. WF-22.19 — Independent Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 911
11.22.20. WF-22.20 — Finality Verification Predicate . . . . 911
11.22.21. WF-22.21 — Protected Runtime Policy Updates Across
Replicas . . . . . . . . . . . . . . . . . . . . . . 912
11.22.22. WF-22.22 — Authorization-State Version
Advancement . . . . . . . . . . . . . . . . . . . . . 913
11.22.23. WF-22.23 — Replica Consistency and Stale Capability
Rejection . . . . . . . . . . . . . . . . . . . . . . 914
11.22.24. WF-22.24 — Hardware-Supervised Cloud Egress . . . . 915
11.22.25. WF-22.25 — Hardware Egress Admission Sequence . . . 915
11.22.26. WF-22.26 — Identification of Runtime Transitions . 916
11.22.27. WF-22.27 — Runtime-Transition State Record . . . . 917
11.22.28. WF-22.28 — Migration of Pending Candidate Acts . . 918
11.22.29. WF-22.29 — Runtime Migration Revalidation
Predicate . . . . . . . . . . . . . . . . . . . . . . 918
11.22.30. WF-22.30 — Snapshot and Checkpoint Restoration . . 919
11.22.31. WF-22.31 — Protected Capability-Consumption State
Across Migration . . . . . . . . . . . . . . . . . . 920
11.22.32. WF-22.32 — Duplicate Effectuation Prevention During
Failover . . . . . . . . . . . . . . . . . . . . . . 920
11.22.33. WF-22.33 — Failover State-Reconciliation
Procedure . . . . . . . . . . . . . . . . . . . . . . 921
11.22.34. WF-22.34 — Model-Access Authorization . . . . . . . 922
11.22.35. WF-22.35 — Separate Downstream Operation
Authorization . . . . . . . . . . . . . . . . . . . . 922
11.22.36. WF-22.36 — Interruption or Revocation of Future Model
Access . . . . . . . . . . . . . . . . . . . . . . . 923
11.22.37. WF-22.37 — Illustrative Cross-Cloud Migration . . . 924
11.22.38. WF-22.38 — Illustrative Kubernetes Replica Policy
Update . . . . . . . . . . . . . . . . . . . . . . . 924
11.22.39. WF-22.39 — Illustrative SmartNIC-Supervised Agent
Egress . . . . . . . . . . . . . . . . . . . . . . . 925
11.22.40. WF-22.40 — Illustrative Snapshot Replay . . . . . . 925
11.22.41. WF-22.41 — Illustrative Model-Path and
Effectuation-Path Separation . . . . . . . . . . . . 926
Das Expires 19 April 2027 [Page 36]
Internet-Draft Protected AI Execution Finality October 2026
11.22.42. WF-22.42 — Time-of-Check and Time-of-Use
Protection . . . . . . . . . . . . . . . . . . . . . 926
11.22.43. WF-22.43 — Fail-Closed Runtime Policy Handling . . 927
11.22.44. WF-22.44 — Alternative Technical Implementations . 928
11.22.45. WF-22.45 — Failure and Fail-Closed Conditions . . . 929
11.22.46. WF-22.46 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 930
11.22.47. WF-22.47 — Claim-Specific Technical Support . . . . 933
11.22.48. WF-22.48 — Technical Effect . . . . . . . . . . . . 935
11.23. WF-23 — Atomic Protected-State Consumption,
Validation-Evidence Commitment, Non-Bearer Capability
Replay Prevention, Crash-Consistent Finality, and
Duplicate-Effect Recovery . . . . . . . . . . . . . . . 937
11.23.1. WF-23.1 — Technical Purpose . . . . . . . . . . . . 937
11.23.2. WF-23.2 — Participating Technical Components . . . 938
11.23.3. WF-23.3 — Establishment of the Protected
Authorization Boundary . . . . . . . . . . . . . . . 941
11.23.4. WF-23.4 — Distinguishing Authorization from
Effectuation . . . . . . . . . . . . . . . . . . . . 942
11.23.5. WF-23.5 — Candidate Act Generation . . . . . . . . 942
11.23.6. WF-23.6 — Candidate Act Identifier and Attempt
Identifier . . . . . . . . . . . . . . . . . . . . . 943
11.23.7. WF-23.7 — Interception and Non-Effective State . . 944
11.23.8. WF-23.8 — Canonical Candidate Act Descriptor . . . 945
11.23.9. WF-23.9 — Protected Grant-State Record . . . . . . 946
11.23.10. WF-23.10 — Grant Eligibility Verification . . . . . 947
11.23.11. WF-23.11 — Atomic Protected-State Transition . . . 947
11.23.12. WF-23.12 — Concurrency and Double-Consumption
Prevention . . . . . . . . . . . . . . . . . . . . . 948
11.23.13. WF-23.13 — Protected Grant Reservation . . . . . . 949
11.23.14. WF-23.14 — Atomic Finality Commit . . . . . . . . . 950
11.23.15. WF-23.15 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 950
11.23.16. WF-23.16 — Capability Preparation Versus Capability
Release . . . . . . . . . . . . . . . . . . . . . . . 951
11.23.17. WF-23.17 — Scoped Non-Bearer Capability . . . . . . 952
11.23.18. WF-23.18 — Current-State Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 953
11.23.19. WF-23.19 — Finality Verification Predicate . . . . 954
11.23.20. WF-23.20 — Capability Consumption at
Effectuation . . . . . . . . . . . . . . . . . . . . 955
11.23.21. WF-23.21 — Formal Candidate Act State Machine . . . 955
11.23.22. WF-23.22 — Protected Effectuation Outcome State . . 956
11.23.23. WF-23.23 — Distinction Between Reserved and Confirmed
Effective . . . . . . . . . . . . . . . . . . . . . . 957
11.23.24. WF-23.24 — Anti-Replay Protection . . . . . . . . . 958
11.23.25. WF-23.25 — Replay-Prevention Predicate . . . . . . 959
Das Expires 19 April 2027 [Page 37]
Internet-Draft Protected AI Execution Finality October 2026
11.23.26. WF-23.26 — Cross-Destination and Cross-Sink Reuse
Prevention . . . . . . . . . . . . . . . . . . . . . 959
11.23.27. WF-23.27 — Retry Following Timeout . . . . . . . . 960
11.23.28. WF-23.28 — Protected Recovery Predicate . . . . . . 961
11.23.29. WF-23.29 — Recovery After Failure Before Protected
Commitment . . . . . . . . . . . . . . . . . . . . . 962
11.23.30. WF-23.30 — Recovery After Commitment but Before
Capability Delivery . . . . . . . . . . . . . . . . . 962
11.23.31. WF-23.31 — Recovery After Capability Delivery but
Before Effectuation . . . . . . . . . . . . . . . . . 963
11.23.32. WF-23.32 — Recovery After Effectuation Attempt . . 964
11.23.33. WF-23.33 — Receiving-Side Reconciliation . . . . . 964
11.23.34. WF-23.34 — Idempotency and Duplicate-Effect
Protection . . . . . . . . . . . . . . . . . . . . . 965
11.23.35. WF-23.35 — Protected Retry Authority . . . . . . . 966
11.23.36. WF-23.36 — Revocation During an Interrupted
Operation . . . . . . . . . . . . . . . . . . . . . . 966
11.23.37. WF-23.37 — Snapshot and State-Rollback
Protection . . . . . . . . . . . . . . . . . . . . . 967
11.23.38. WF-23.38 — Distributed Protected-State
Consistency . . . . . . . . . . . . . . . . . . . . . 967
11.23.39. WF-23.39 — Atomicity and Remote-Effect
Limitation . . . . . . . . . . . . . . . . . . . . . 968
11.23.40. WF-23.40 — Illustrative Atomic Grant Consumption . 969
11.23.41. WF-23.41 — Illustrative Crash Before Capability
Release . . . . . . . . . . . . . . . . . . . . . . . 970
11.23.42. WF-23.42 — Illustrative Timeout After
Credential-Mediated Effectuation . . . . . . . . . . 970
11.23.43. WF-23.43 — Illustrative Snapshot Replay . . . . . . 971
11.23.44. WF-23.44 — Illustrative Cross-Sink Capability
Reuse . . . . . . . . . . . . . . . . . . . . . . . . 971
11.23.45. WF-23.45 — Alternative Technical Implementations . 972
11.23.46. WF-23.46 — Failure and Fail-Closed Conditions . . . 973
11.23.47. WF-23.47 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . . 974
11.23.48. WF-23.48 — Claim-Specific Technical Support . . . . 977
11.23.49. WF-23.49 — Technical Effect . . . . . . . . . . . . 978
11.24. WF-24 — Multiple Finality Sinks, Independent Downstream
Verification, Multi-Boundary Candidate Act Classification,
Receiving-Side Finality, and Protected Cross-Boundary
Execution Authority . . . . . . . . . . . . . . . . . . 979
11.24.1. WF-24.1 — Technical Purpose . . . . . . . . . . . . 980
11.24.2. WF-24.2 — Participating Technical Components . . . 981
11.24.3. WF-24.3 — Distinction Between Computation and
Effectuation . . . . . . . . . . . . . . . . . . . . 984
11.24.4. WF-24.4 — Identification of Distinct Effectuation
Classes . . . . . . . . . . . . . . . . . . . . . . . 985
11.24.5. WF-24.5 — Effectuation Boundary Registry . . . . . 985
Das Expires 19 April 2027 [Page 38]
Internet-Draft Protected AI Execution Finality October 2026
11.24.6. WF-24.6 — Classification of a Multi-Operation
Workflow . . . . . . . . . . . . . . . . . . . . . . 986
11.24.7. WF-24.7 — Separation of Delegation from Downstream
Effectuation . . . . . . . . . . . . . . . . . . . . 987
11.24.8. WF-24.8 — Delegation Acceptance Boundary . . . . . 988
11.24.9. WF-24.9 — Subordinate-Agent Candidate Act . . . . . 988
11.24.10. WF-24.10 — Separation of Model Admission from
Downstream Effectuation . . . . . . . . . . . . . . . 989
11.24.11. WF-24.11 — Inference-to-Act Context Binding . . . . 990
11.24.12. WF-24.12 — Candidate Act Generation and Holding . . 990
11.24.13. WF-24.13 — Operation-Specific Descriptor
Formation . . . . . . . . . . . . . . . . . . . . . . 991
11.24.14. WF-24.14 — Canonical Candidate Act
Representation . . . . . . . . . . . . . . . . . . . 992
11.24.15. WF-24.15 — Operation-Specific Authority
Validation . . . . . . . . . . . . . . . . . . . . . 993
11.24.16. WF-24.16 — Protected Authorization Predicate . . . 994
11.24.17. WF-24.17 — Protected Authorization-State
Handling . . . . . . . . . . . . . . . . . . . . . . 994
11.24.18. WF-24.18 — Protected Validation-Evidence
Commitment . . . . . . . . . . . . . . . . . . . . . 995
11.24.19. WF-24.19 — Scoped Execution-Capability Release . . 996
11.24.20. WF-24.20 — Independent Finality Sink
Verification . . . . . . . . . . . . . . . . . . . . 997
11.24.21. WF-24.21 — Effectuation Verification Predicate . . 998
11.24.22. WF-24.22 — Multi-Sink Capability Independence . . . 998
11.24.23. WF-24.23 — Receiving-Side Finality . . . . . . . . 999
11.24.24. WF-24.24 — Remote Actual-Operation Descriptor . . .1000
11.24.25. WF-24.25 — Receiving-Side Verification Predicate .1000
11.24.26. WF-24.26 — Source-Side Transmission and
Receiving-Side Commitment . . . . . . . . . . . . . .1001
11.24.27. WF-24.27 — Streaming Outputs and Partial Actions .1002
11.24.28. WF-24.28 — Buffering of Consequential Streaming
Output . . . . . . . . . . . . . . . . . . . . . . .1003
11.24.29. WF-24.29 — Model-Access Interruption and Buffered
Operations . . . . . . . . . . . . . . . . . . . . .1003
11.24.30. WF-24.30 — Multi-Hop Agent Workflow . . . . . . . .1004
11.24.31. WF-24.31 — Scoped Multi-Stage Authorization . . . .1004
11.24.32. WF-24.32 — Cross-Boundary Context Continuity . . .1005
11.24.33. WF-24.33 — Separate Credential Application . . . .1006
11.24.34. WF-24.34 — Separate Persistent-State Commitment . .1006
11.24.35. WF-24.35 — Separate Payment Effectuation . . . . .1006
11.24.36. WF-24.36 — Cross-Sink Capability Substitution . . .1007
11.24.37. WF-24.37 — Protected State Across Multiple Sinks .1007
11.24.38. WF-24.38 — Revocation Across Consequential
Boundaries . . . . . . . . . . . . . . . . . . . . .1008
11.24.39. WF-24.39 — Protected Operation Outcomes . . . . . .1008
Das Expires 19 April 2027 [Page 39]
Internet-Draft Protected AI Execution Finality October 2026
11.24.40. WF-24.40 — Crash and Recovery Across Multiple
Finality Sinks . . . . . . . . . . . . . . . . . . .1009
11.24.41. WF-24.41 — Receiving-Side Completion
Reconciliation . . . . . . . . . . . . . . . . . . .1010
11.24.42. WF-24.42 — Illustrative End-to-End Enterprise Agent
Workflow . . . . . . . . . . . . . . . . . . . . . .1011
11.24.43. WF-24.43 — Illustrative Remote Payment
Verification . . . . . . . . . . . . . . . . . . . .1012
11.24.44. WF-24.44 — Illustrative Model-Quarantine
Scenario . . . . . . . . . . . . . . . . . . . . . .1012
11.24.45. WF-24.45 — Illustrative Delegated-Agent Boundary .1013
11.24.46. WF-24.46 — Illustrative Cross-Sink Replay . . . . .1013
11.24.47. WF-24.47 — Alternative Technical Implementations .1014
11.24.48. WF-24.48 — Failure and Fail-Closed Conditions . . .1015
11.24.49. WF-24.49 — PHOSITA Verification and Negative
Tests . . . . . . . . . . . . . . . . . . . . . . . .1016
11.24.50. WF-24.50 — Claim-Specific Technical Coverage . . .1019
11.24.51. WF-24.51 — Technical Effect . . . . . . . . . . . .1020
12. Deployment Contexts . . . . . . . . . . . . . . . . . . . . .1022
13. Technical Enforcement Points and Boundary Conditions . . . .1031
13.1. EP-01: Protected AI-Agent Sandbox Egress Finality
System . . . . . . . . . . . . . . . . . . . . . . . .1031
13.2. EP-02: Sandbox Boundary Interception . . . . . . . . . .1033
13.3. EP-03: Concrete Act Descriptor . . . . . . . . . . . . .1033
13.4. EP-04: Intent, Logic and Behavioral Verification . . . .1033
13.5. EP-05: Untrusted Content and Taint-Lineage Governance .1034
13.6. EP-06: Network Egress Finality . . . . . . . . . . . . .1034
13.7. EP-07: Credential Broker Finality . . . . . . . . . . .1034
13.8. EP-08: File, Shell and Host-System Enforcement . . . . .1035
13.9. EP-09: Protected Human Approval . . . . . . . . . . . .1035
13.10. EP-10: Agent-Initiated Policy Mutation . . . . . . . . .1035
13.11. EP-11: Sub-Agent Delegation . . . . . . . . . . . . . .1036
13.12. EP-12: Continuous Egress Validation . . . . . . . . . .1036
13.13. EP-13: Revocation and Policy-Epoch Enforcement . . . . .1036
13.14. EP-14: Hardware-Rooted Enforcement . . . . . . . . . . .1037
13.15. EP-15: Browser and Computer-Use Finality . . . . . . . .1037
13.16. EP-16: Autonomous Commerce . . . . . . . . . . . . . . .1037
13.17. EP-17: Privacy-Preserving Validation Receipt . . . . . .1038
13.18. EP-18: Fail-Closed Denial and Containment . . . . . . .1038
13.19. EP-19: Canonical Authorization-to-Execution Binding . .1038
13.20. EP-20: Protected Grant-State Consumption . . . . . . . .1038
13.21. EP-21: Atomic Credential-Release Transaction . . . . . .1039
13.22. EP-22: Privileged Connector Verification . . . . . . . .1039
13.23. EP-23: Destination Resolution and Redirect
Consistency . . . . . . . . . . . . . . . . . . . . . .1039
13.24. EP-24: Crash, Retry and Duplicate-Effect Protection . .1040
13.25. EP-25: Process-Lineage Authority Degradation . . . . . .1040
13.26. EP-26: Policy Mutation Activation Interlock . . . . . .1040
Das Expires 19 April 2027 [Page 40]
Internet-Draft Protected AI Execution Finality October 2026
13.27. EP-27: Cross-Component Finality Consistency . . . . . .1041
13.28. EP-28: Transaction-Bound Agent Authorization and
Credential Effectuation System . . . . . . . . . . . .1041
13.29. EP-29: Protected Credential Substitution . . . . . . . .1042
13.30. EP-30: Independent Executor Attestation . . . . . . . .1043
13.31. EP-31: Protected Effectuation Outcome State . . . . . .1043
13.32. EP-32: Method of Protected Agent Egress Finality . . . .1043
13.33. EP-33: State-Bound Finality and Replay Protection . . .1044
13.34. EP-34: Protected Self-Modification Finality System . . .1045
13.35. EP-35: Before-and-After Policy Binding . . . . . . . . .1046
13.36. EP-36: Evaluation and Regression Evidence . . . . . . .1046
13.37. EP-37: Developer Approval as a Protected Predicate . . .1046
13.38. EP-38: Runtime Revocation and Mutation Revalidation . .1046
13.39. EP-39: Protected Sub-Agent Delegation Finality System .1047
13.40. EP-40: Child-Agent Scope Restriction . . . . . . . . . .1048
13.41. EP-41: Recursive Delegation Control . . . . . . . . . .1048
13.42. EP-42: Separation of Delegation from Downstream
Effectuation . . . . . . . . . . . . . . . . . . . . .1048
13.43. EP-43: Protected Autonomous Code-Deployment Finality
System . . . . . . . . . . . . . . . . . . . . . . . .1048
13.44. EP-44: Artifact and Commit Binding . . . . . . . . . . .1049
13.45. EP-45: Protected Signing or Publication Key . . . . . .1050
13.46. EP-46: Agent-Generated Skill Deployment . . . . . . . .1050
13.47. EP-47: Staged Deployment and Drift Interruption . . . .1050
13.48. EP-48: Protected Cross-Domain AI-Fabric Transfer Finality
System . . . . . . . . . . . . . . . . . . . . . . . .1050
13.49. EP-49: Fabric Transfer Descriptor Granularity . . . . .1052
13.50. EP-50: Hardware-Latched Transfer Admission . . . . . . .1052
13.51. EP-51: Continuous Tensor or Memory-Transfer
Validation . . . . . . . . . . . . . . . . . . . . . .1052
13.52. EP-52: Hardware-Freshness Binding . . . . . . . . . . .1052
13.53. EP-53: Separated Cold-Path Validation and Line-Rate
Finality . . . . . . . . . . . . . . . . . . . . . . .1053
13.54. EP-54: Protected Pre-Computation Model Admission
System . . . . . . . . . . . . . . . . . . . . . . . .1053
13.55. EP-55: Model and Workflow Measurement Binding . . . . .1054
13.56. EP-56: Protected Model-Loader Admission . . . . . . . .1054
13.57. EP-57: Separate Downstream Execution Authority . . . . .1054
13.58. EP-58: Protected Service-Mesh Effectuation System . . .1055
13.59. EP-59: Service Identity and Session Binding . . . . . .1056
13.60. EP-60: Service-Mesh Bypass Prevention . . . . . . . . .1056
13.61. EP-61: Fail-Closed Route and Policy Mismatch . . . . . .1056
13.62. EP-62: Distributed Hardware-Watchdog Execution Interlock
System . . . . . . . . . . . . . . . . . . . . . . . .1056
13.63. EP-63: Hardware-Attested Monitoring State . . . . . . .1057
13.64. EP-64: Watchdog-to-Finality Revocation Fence . . . . . .1057
13.65. EP-65: Prevention Despite Continued Model Access . . . .1058
13.66. EP-66: Monitoring Failure and Stale-State Handling . . .1058
Das Expires 19 April 2027 [Page 41]
Internet-Draft Protected AI Execution Finality October 2026
13.67. EP-67: Quarantine with Effectuation-State
Preservation . . . . . . . . . . . . . . . . . . . . .1058
13.68. EP-68: Model-Path and Effectuation-Path Dual Authorization
System . . . . . . . . . . . . . . . . . . . . . . . .1058
13.69. EP-69: Inference-to-Act Context Binding . . . . . . . .1060
13.70. EP-70: Streaming Output and Partial-Action Control . . .1060
13.71. EP-71: Multi-Sink Effectuation Classification . . . . .1060
13.72. EP-72: Remote Effectuation Verification . . . . . . . .1060
13.73. EP-73: Confidential Cloud AI-Agent Execution and
Cryptographic Finality . . . . . . . . . . . . . . . .1061
13.74. EP-74: Hardware-Rooted Composite ALF . . . . . . . . . .1062
13.75. EP-75: Measured Workload Configuration . . . . . . . . .1062
13.76. EP-76: Privacy-Preserving Cryptographic Validation . . .1063
13.77. EP-77: Cloud Tenant and Destination Scope . . . . . . .1063
13.78. EP-78: Virtual-Machine Snapshot Replay Resistance . . .1063
13.79. EP-79: Confidential Governance VM and Hardware-Attested
SmartNIC Finality . . . . . . . . . . . . . . . . . . .1063
13.80. EP-80: Confidential VM Attestation Object . . . . . . .1064
13.81. EP-81: Confidential Governance-Key Isolation . . . . . .1065
13.82. EP-82: Attestation Change Disables Capability
Issuance . . . . . . . . . . . . . . . . . . . . . . .1065
13.83. EP-83: Cryptographically Bound Hardware Freshness . . .1065
13.84. EP-84: User-Controlled Confidential VM with
Cryptographically Bound Execution Authority . . . . . .1065
13.85. EP-85: User-Held Root-Key and Attested Derived-Key
Release . . . . . . . . . . . . . . . . . . . . . . . .1066
13.86. EP-86: Dual Authorization for Decryption and External
Effect . . . . . . . . . . . . . . . . . . . . . . . .1067
13.87. EP-87: Cryptographic Binding of Confidential-VM State to
Candidate Act . . . . . . . . . . . . . . . . . . . . .1067
13.88. EP-88: Privacy-Preserving Execution Evidence . . . . . .1067
13.89. EP-89: Confidential-VM Recovery and Key-State
Continuity . . . . . . . . . . . . . . . . . . . . . .1068
13.90. EP-90: Portable Cloud-VM Agent Authority and Hardware
Effectuation System . . . . . . . . . . . . . . . . . .1068
13.91. EP-91: VM and Container Identity Attestation . . . . . .1069
13.92. EP-92: Runtime Policy Changes Across Cloud Replicas . .1069
13.93. EP-93: Hardware-Supervised Cloud Egress . . . . . . . .1070
13.94. EP-94: Cross-Runtime Migration and Snapshot
Protection . . . . . . . . . . . . . . . . . . . . . .1070
13.95. EP-95: Model-Path Authorization Does Not Replace
Effectuation Authorization . . . . . . . . . . . . . .1070
14. Security Considerations . . . . . . . . . . . . . . . . . . .1070
14.1. Threat Model and Enforcement Coverage . . . . . . . . .1071
14.2. Canonicalization and Operation Substitution . . . . . .1071
14.3. Capability Protection and Context Binding . . . . . . .1071
14.4. Protected State, Revocation, and Fail-Closed Behavior .1071
14.5. Credential and Delegation Boundaries . . . . . . . . . .1072
Das Expires 19 April 2027 [Page 42]
Internet-Draft Protected AI Execution Finality October 2026
14.6. Monitoring Versus Prevention . . . . . . . . . . . . . .1072
14.7. Remote Completion and Recovery Limits . . . . . . . . .1072
14.8. Operational Assurance and Testing . . . . . . . . . . .1072
15. Relationship to Existing Standards . . . . . . . . . . . . .1073
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1073
17. References . . . . . . . . . . . . . . . . . . . . . . . . .1073
Author's Address . . . . . . . . . . . . . . . . . . . . . . . .1073
1. Status, Scope, and Interpretation
This document presents technical enforcement approaches for Internet
community review. Terminology such as Candidate Act, Protected
Enforcement Domain, and Finality Sink denotes architectural
functions; it is not intended to state patent claim scope. The
collection of techniques is not a single mandatory interoperable
profile. Deployment claims of non-bypassability and fail-closed
operation require implementation-specific threat models and evidence.
2. Industry Terminology and Technical Scope
This document examines AI-agent sandbox isolation, independent
permission authorities, mandatory network-egress enforcement,
credential brokering, runtime policy controls, and hardware-assisted
security mechanisms discussed in publicly documented systems
including Meta Muse/Sentinel and NVIDIA OpenShell/Sentry, with
particular attention to protected authorization-state commitment,
act-bound non-bearer execution capabilities, and independent
verification at consequential effectuation boundaries.
Contemporary AI-agent security architectures are described using
terminology such as sandboxed agent execution, out-of-process policy
enforcement, isolated agent runtimes, mandatory network-egress
mediation, credential brokering, privileged connectors, executable-
specific permissions, runtime policy approval, hardware-assisted
monitoring, and model-access governance.
Public implementations and architectural discussions associated with
these areas include Meta Muse/Sentinel and NVIDIA OpenShell,
NemoClaw, and the Open Agent Safety Platform, including Sentry and
BlueField-based monitoring and enforcement. These references
identify relevant engineering contexts and publicly used terminology;
they do not establish architectural identity, implementation
equivalence, historical priority, or the presence of every mechanism
described in this document.
Industry and product names in this document are used solely as
factual identifiers and search terminology to illustrate the
relevance of public technical discussions and to facilitate
Das Expires 19 April 2027 [Page 43]
Internet-Draft Protected AI Execution Finality October 2026
independent architectural examination. All such names and trademarks
remain the property of their respective owners. Their inclusion does
not imply endorsement, affiliation, sponsorship, access to nonpublic
information, copying, derivation, infringement, validity or scope of
any patent claim, or that the named systems implement the complete
mechanisms described here. Any functional correspondence must be
evaluated from dated primary technical disclosures; chronology and
patent priority require separate documentary and legal assessment.
The architecture described here additionally examines the technical
conditions under which a generated operation acquires authority to
produce a consequential effect. Its principal proposed enforcement
sequence includes:
1. Mandatory interception of a proposed Candidate Act before its
governed effectuation boundary.
2. Maintenance of the Candidate Act in a Non-Effective State.
3. Construction of a verifiable, effectuation-relevant Candidate Act
Descriptor.
4. Protected authorization-predicate validation and required
protected-state handling.
5. Commitment of mandatory validation evidence before, or atomically
with, scoped execution-capability availability.
6. Release or activation of an act-bound, non-bearer execution
capability.
7. Verification of that capability against the actual operation and
required current state at the applicable Finality Sink.
8. Fail-closed withholding where mandatory verification fails.
The architecture distinguishes sandbox confinement, policy approval,
credential isolation, computation admission, hardware monitoring, and
post-event quarantine from the separate authorization conditions
required for a consequential downstream operation.
It addresses enforcement arrangements involving agent runtimes,
network proxies, API gateways, credential brokers, cloud service
meshes, protected storage interfaces, confidential virtual machines,
SmartNICs, data processing units, accelerator fabrics, and receiving-
side execution interfaces.
Das Expires 19 April 2027 [Page 44]
Internet-Draft Protected AI Execution Finality October 2026
Computation, possession of a credential reference, admission to a
model, or successful execution within a protected runtime does not
independently confer authority to complete every downstream
consequential operation. Each separately governed effectuation
boundary remains subject to its applicable authorization and
verification requirements.
This document presents these mechanisms for technical examination and
does not assert that the named industry systems implement the
complete described sequence, derive from this work, or satisfy
equivalent security guarantees.
3. Technical Discoverability and Architectural Terminology
This section supplies search terminology and technical examination
questions for readers studying AI-agent security architectures,
including the publicly described Meta Muse and Sentinel architecture
announced on 8 September 2026. It is a discoverability and
engineering-comparison aid, not an assertion of copying,
infringement, patentability, identity, or adoption by Meta. Product-
specific descriptions should be independently checked against the
original dated Meta publication and any relevant as-released
technical materials.
3.1. Product Names and Search Expressions
Examples of text search expressions that may help locate discussions
of the named system and related protected execution mechanisms
follow. They are suggested queries rather than claims about any
patent examiner's actual search practice.
* "Meta Muse" "Sentinel" "AI agent"
* "Muse Secure VM" "sandbox" "agent"
* "Sentinel" "permission authority" "egress"
* "surrogate credential" "credential broker" "proxy"
* "agent" "egress" "destination" "policy"
* "Sentinel" "privileged connector" "host worker"
* "Muse" "taint" "eBPF" "LSM"
* "Meta Muse" "approval" "tool execution"
* "agent" "concrete operation" "authorization"
Das Expires 19 April 2027 [Page 45]
Internet-Draft Protected AI Execution Finality October 2026
* "Candidate Act" "Finality Sink" "execution capability"
* "AI-agent sandbox security" "independent host-side permission
authority"
* "network egress enforcement" "protected credential brokering"
* "concrete-operation authorization" "act-bound execution
capabilities"
* "independent effectuation-boundary verification" "downstream
consequence"
3.2. Published-System Vocabulary and Corresponding Technical
Examination Topics
In public descriptions of Meta Muse/Sentinel, the following
terminology provides starting points for examination. The adjacent
execution-finality terminology identifies a question or possible
functional correspondence, not an assertion that Meta provides the
full execution-finality mechanism.
* Sentinel as a host-side or outside-runtime permission authority:
examine isolation of authorization logic and state from the agent;
compare to a Protected Enforcement Domain (PED) only to the extent
its protected authority functions are established.
* Muse runtime and isolated agent execution cell, including the Muse
Secure VM: examine sandbox boundaries, mandatory mediation,
privileged host services, and all reachable bypass paths.
* Agent-generated actions subject to Sentinel allow, deny, or ask
decisions: examine separation of computation from permission
authority, the concreteness of the request checked, and human
approval as a protected predicate.
* Controlled forward proxy and host-side network egress: examine
executable, destination, protocol, port, HTTP method and path,
decoded request content, DNS resolution, selected IP address,
redirect, connection reuse, and the actual governed network
effect.
* Credential isolation, surrogate credentials, host credential
services, and just-in-time application of real credentials:
examine non-authoritative references, credential custody,
authenticated connector identity, concrete request binding, and
whether credential use is separately verified at the effectuation
interface.
Das Expires 19 April 2027 [Page 46]
Internet-Draft Protected AI Execution Finality October 2026
* Privileged host-side connectors or workers: examine separated
connector execution, authenticated service interfaces, granted
credential allowlists, and verification of requested operations.
* Provenance, taint, eBPF and Linux Security Module (LSM)
enforcement: examine how lower-trust input influences process,
subprocess, session, or action lineage and whether that influence
changes automatic permissions or requires escalated approval.
* Approval workflows and runtime policy changes: examine what an
authorized developer or user approves, whether the approval
matches the actual operation, and whether subsequent policy or
revocation state invalidates earlier permission.
* Execution-finality terms for separate study: Candidate Act, Non-
Effective State (NES), Candidate Act Descriptor (CAD), protected
validation-evidence commitment, scoped non-bearer capability,
Finality Gate, Finality Sink, protected grant consumption, and
independent receiving-side effectuation verification.
3.3. Five Technical Examination Questions
These questions distinguish ordinary permission controls from the
more specific causal requirements discussed elsewhere in this draft.
* Authority separation: is permission controlled independently of
the agent, and which protected component exclusively manages
applicable validation logic, state, and enablement?
* Concrete-operation binding: which exact request, destination,
executable or connector, credential scope, requesting context,
payload attributes, and policy version are validated?
* Protected authorization state: how are grants, usage limits,
policy changes, revocation, nonce freshness, reservation, and
consumption handled under concurrent or retried operations?
* Execution enablement: does the implementation use an internal
allow/deny/ask decision or a separately authenticated and scoped
capability, and if a capability exists, what actual verifier
checks its bindings?
* Final enforcement boundary: is the actual consequential operation
verified immediately before effectuation, and does upstream
network permission remain distinct from receiving-side database
commitment, payment execution, storage modification, or other
separately governed effects?
Das Expires 19 April 2027 [Page 47]
Internet-Draft Protected AI Execution Finality October 2026
3.4. Specific Architectural Distinctions Requiring Verification
An isolated runtime, a policy decision, an egress proxy, and
credential secrecy can each be valuable safeguards without
independently proving that validation evidence was committed before
capability availability, that an act-bound non-bearer capability was
issued, or that a distinct Finality Sink verification occurred.
In the protected execution-finality sequence described in this
document, the proposed consequential operation is intercepted and
held non-effective; an effectuation-relevant descriptor is formed;
required protected authority predicates and state are checked;
required validation evidence is committed before or atomically with
capability availability; a scoped non-bearer execution capability is
made available; the applicable Finality Sink checks that capability
against the actual operation and mandatory current state; failure
leaves the governed operation non-effective.
The Finality Sink and PED are functionally distinct in this sequence
but need not be in different physical devices. Whether Meta Muse/
Sentinel employs equivalent separate state, receipt, capability,
consumption, or sink-verification conditions requires affirmative
evidence, not inference from a host-side permission check.
Source-side network forwarding authority does not itself establish
receiving-side authorization for database mutation, financial
settlement, persistent storage commit, or physical actuation.
Similarly, stopping model inference or quarantining a workload after
detection cannot retroactively prevent an already completed
operation.
Product names and terms appearing here are provided for independent
research and keyword discoverability. They do not establish that a
patent application supports a claimed combination at an earlier date;
that assessment requires reading the particular as-filed application
independently.
3.5. Combined Technical Search Phrase
AI-agent sandbox security; independent host-side permission
authority; network egress enforcement; protected credential
brokering; concrete-operation authorization; act-bound execution
capabilities; independent effectuation-boundary verification;
privileged connectors; eBPF/LSM provenance and taint; developer
approval; multi-sink downstream execution control.
Das Expires 19 April 2027 [Page 48]
Internet-Draft Protected AI Execution Finality October 2026
Industry terms are not defined as interchangeable with architectural
components merely by their juxtaposition. A technical evaluation
should distinguish announced behavior, implemented code, functional
overlap, different enforcement guarantees, and missing evidence.
4. Author-Reported Indian Filing Chronology and Underlying Concepts
The author identifies Indian application No. 202531130665, with a
reported corrected filing date of 23 December 2025, as an earlier
Indian filing concerning underlying execution-authority and
execution-boundary concepts. The application number and corrected
date are author-reported and are not independently authenticated in
this Internet-Draft.
The author further identifies separate Indian provisional
applications dated 3 January, 7 January, and 12 January 2026 as
earlier technical filings addressing aspects of cryptographic
execution-time enforcement, protected authority at consequential
commit or settlement boundaries, and multi-authority context-
dependent execution authorization, respectively. Their individual
disclosures must be examined independently when assessing support for
any particular mechanism or combination.
Indian application No. 202631124028 is separately identified below as
patent pending. This document does not establish that this
application was filed in January 2026 or that it is legally entitled
to the filing date of any earlier application. Priority entitlement,
incorporation, continuity, and support for specific subject matter
depend on the relevant official application records and the
disclosures actually present in each filing.
The dates and application identifiers in this subsection provide
research and patent-disclosure context only; they do not assert that
all architectural features, workflows, or enforcement points in this
Internet-Draft were disclosed on 23 December 2025 or in any single
January 2026 application.
5. Related Patent Applications and Intellectual Property Disclosure
Patent-pending notice: The author identifies Indian patent
application No. 202631124028 as a patent application associated with
the general subject area of protected AI-agent execution and
execution-finality enforcement. Its filing date, exact disclosure
coverage, prosecution status, and relationship to particular portions
of this Internet-Draft have not been independently verified in this
document. The application number is provided for discoverability,
not as a statement of a granted patent, formal priority entitlement,
or incorporation by reference.
Das Expires 19 April 2027 [Page 49]
Internet-Draft Protected AI Execution Finality October 2026
The author also identifies the following earlier Indian and
international applications as related technical disclosures.
Identifiers and reported publication designations are included to
facilitate independent inspection of the underlying records. Each
application remains a distinct document; listing applications
together does not establish that a particular integrated technical
combination is disclosed in any one of them.
5.1. Indian Applications and Earlier Disclosures
Indian provisional application dated 3 January 2026: Cryptographic
Execution-Time Enforcement System with Purpose- and Jurisdiction-
Bound Authorization and Split Execution Control (application number
not stated here).
Indian provisional application dated 7 January 2026: Systems and
Methods for Cryptographic Enforcement of Execution Authority at
Commit-Time, Settlement-Time, and Other Irreversible System
Boundaries in Distributed, Hardware-Backed Digital Systems
(application number not stated here).
Indian provisional application dated 12 January 2026: Systems and
Methods for Execution-Time Authorization Using Multi-Authority,
Quantum-Resilient, and Context-Adaptive Cryptographic Enforcement at
Irreversible Execution Boundaries (application number not stated
here).
Indian application No. 202631124028: identified by the author as
patent pending; the specific linkage to any earlier priority document
is not established by this listing.
5.2. International Patent Application Identifiers
Mothership baseline: PCT/IB2025/058316. No publication designation
is asserted here. Filed in 2025 (author-reported date: 17 August
2025); no publication number has been verified for this entry.
ALF-PCT: PCT/IB2026/053385. Reported publication: WO 2026/115520 A2.
Published 4 June 2026.
DAS Protocols I: PCT/IB2026/055615. Reported publication: WO
2026/150382. Published 16 July 2026.
DAS Protocols II: PCT/IB2026/055760. Reported publication: WO
2026/150383. Published 16 July 2026.
DAS Protocols III: PCT/IB2026/055870. Reported publication: WO
2026/150384. Published 16 July 2026.
Das Expires 19 April 2027 [Page 50]
Internet-Draft Protected AI Execution Finality October 2026
DAS Protocols IV: PCT/IB2026/056058. Reported publication: WO
2026/154461 A2. Published 23 July 2026.
DAS Protocols V: PCT/IB2026/056809. Reported publication: WO
2026/172334. Published August 2026 (exact publication date not
verified here).
DAS Protocols VI: PCT/IB2026/056941. No publication designation is
asserted here. Filing identifier supplied by the author; no verified
publication designation is stated.
5.3. Publication, Priority, and Scope Distinctions
A PCT filing and an international publication are distinct events; an
unpublished application must not be described as publicly available
merely because a filing identifier exists. Publication identifiers
and dates should be checked against WIPO PATENTSCOPE or official
filing records before being relied upon as documentary evidence.
A patent application reference does not by itself establish
patentability, validity, enforceable claim scope, ownership,
effective priority for a specific technical feature, or an
implemented and tested system. A later document cannot acquire
earlier support for a particular combination merely by listing
multiple earlier filings. Technical and priority assessments require
the actual as-filed passages of each relevant application.
5.4. IETF IPR Disclosure Process
This bibliographic notice is separate from the IETF intellectual-
property-rights disclosure process. If applicable patent rights
cover technology proposed for adoption or implementation in an IETF
contribution, the relevant IETF IPR disclosure obligations and
procedures must be addressed separately under the current IETF rules.
This document does not state licensing terms or assert that an IETF
IPR disclosure has been submitted for application No. 202631124028.
The named industry architectures are mentioned only to aid technical
search and discussion. Their inclusion is not an allegation of
infringement, copying, technical derivation, or equivalence.
6. Scope and Technical Field
[0001] the proposed architecture relates generally to computer
security, artificial-intelligence systems, autonomous software
agents, distributed computing, confidential computing, hardware-
assisted enforcement, cryptographic authorization, and protection of
consequential computer operations.
Das Expires 19 April 2027 [Page 51]
Internet-Draft Protected AI Execution Finality October 2026
[0002] More particularly, the architecture relates to systems and
methods for separating the generation, computation, preparation,
staging, or selection of an operation from the protected authority
required to cause that operation to become externally effective.
[0003] the architecture further relates to non-bypassable execution-
finality enforcement, protected authorization-state management,
operation-specific cryptographic capabilities, credential-release
controls, confidential virtual machines, hardware attestation, agent
delegation, sandbox egress, executable-specific permissions, multi-
boundary authorization, accelerator and network-fabric transfers,
hardware watchdogs, SmartNIC and data processing unit enforcement,
cross-cloud workload portability, and fail-closed recovery.
[0004] the architecture may be implemented in artificial-intelligence
agent environments, enterprise computing, cloud and hybrid-cloud
infrastructures, autonomous coding systems, software-development
agents, model-serving infrastructure, protected tool execution,
secure network interfaces, connected-service systems, storage
controllers, transaction-processing systems, accelerators, and cyber-
physical environments.
[0005] the architecture is not restricted to any particular
artificial-intelligence model, operating system, virtualization
platform, processor architecture, cloud service provider,
cryptographic algorithm, hardware vendor, or application protocol.
7. Background and Motivation
7.1. 1. Development of Autonomous Artificial-Intelligence Execution
Systems
[0006] Artificial-intelligence systems have evolved from
predominantly informational processing systems into computational
environments capable of generating, requesting, preparing, and
initiating operations having practical consequences beyond the
immediate model-computation process.
[0007] Contemporary AI-agent environments may access enterprise
information, generate software artifacts, invoke tools, initiate
network communications, interact with external APIs, read or modify
files, perform database operations, access connected services,
coordinate subordinate agents, initiate deployments, and prepare
financial or infrastructure-control instructions.
Das Expires 19 April 2027 [Page 52]
Internet-Draft Protected AI Execution Finality October 2026
[0008] An artificial-intelligence agent may autonomously select an
execution path, determine tool arguments, construct a network
request, or sequence several dependent operations without requiring a
separate human decision for every intermediate computational step.
[0009] Such systems introduce a technical distinction between the
generation of a proposed operation and the authority required to
produce its practical consequence.
[0010] A computational component may be capable of constructing an
executable operation while lacking independent authority to complete
that operation.
[0011] This distinction becomes particularly significant where an
operation can produce persistent, externally visible, financially
consequential, security-sensitive, cryptographically binding, or
physically effective results.
[0012] Examples include disclosure of confidential information,
execution of production commands, modification of protected
databases, application of privileged credentials, publication of
software artifacts, transfer of accelerator-resident data, and
transmission of commands to external infrastructure.
[0013] A principal technical problem is therefore how to permit
useful autonomous computation while ensuring that the corresponding
consequential operation cannot become effective unless the required
protected authorization conditions are satisfied.
7.2. 2. Limitations of Conventional Authentication and Authorization
[0014] Conventional computing systems employ authentication, access-
control lists, role-based access control, attribute-based access
control, delegated permissions, access tokens, API credentials,
operating-system permissions, network access rules, and related
mechanisms to restrict access to resources.
[0015] These mechanisms are useful and may provide strong security
guarantees within their configured scopes.
[0016] However, the fact that a process is authenticated or has
access to a resource does not necessarily establish that every
concrete consequential operation generated by the process has been
separately evaluated against current operation-specific authority.
Das Expires 19 April 2027 [Page 53]
Internet-Draft Protected AI Execution Finality October 2026
[0017] An authenticated AI agent may possess a valid service
credential while preparing a request involving an unauthorized
destination, changed recipient, excessive transaction amount,
prohibited data scope, or another context not permitted by the
governing authority.
[0018] A permission may apply to an account, service, application,
process, resource, or session rather than being cryptographically or
otherwise verifiably bound to the complete effectuation-relevant
attributes of a particular operation.
[0019] Similarly, an earlier authorization decision may become stale
following a change in protected policy, delegation scope, workload
identity, execution environment, revocation state, or resource
configuration.
[0020] A technical need therefore exists for arrangements in which
authorization of a concrete operation is enforced at the boundary
where that operation would acquire its governed practical effect.
7.3. 3. Separation of Computation and Execution Authority
[0021] Artificial-intelligence computation and execution authority
are distinguishable functions.
[0022] Computation may include inference, reasoning, planning,
simulation, tool selection, code generation, request preparation, and
construction of executable instructions.
[0023] Execution authority determines whether a particular proposed
operation is permitted to cross the relevant boundary and produce a
consequential effect.
[0024] Conventional security arrangements may combine these functions
within one process or application-controlled workflow.
[0025] Where the requesting process can modify or bypass its own
authorization logic, protected policy state, or enforcement
mechanism, the resulting authority separation may be insufficient for
the specified threat model.
[0026] Accordingly, there is a need for architectures in which
protected validation logic, authorization state, and execution-
enablement authority are isolated from unilateral control by the
requesting computational component.
Das Expires 19 April 2027 [Page 54]
Internet-Draft Protected AI Execution Finality October 2026
[0027] The computational component may continue generating proposals,
but it cannot independently confer protected execution authority upon
those proposals.
7.4. 4. Limitations of Sandboxing and Process Isolation Alone
[0028] Sandboxes, containers, virtual machines, restricted runtimes,
operating-system permissions, and process-isolation mechanisms are
established approaches for controlling software behavior.
[0029] These mechanisms can restrict accessible files, processes,
system calls, network destinations, credentials, and other resources.
[0030] Nevertheless, an isolated agent may legitimately possess
access to selected tools, services, or interfaces capable of
producing consequential effects.
[0031] A sandbox may therefore prevent some prohibited activity while
still requiring an additional authorization decision for a concrete
operation passing through an otherwise permitted interface.
[0032] For example, an agent may be authorized to invoke an
enterprise API but not to submit every possible request or parameter
combination supported by that API.
[0033] Likewise, permission to communicate with an approved hostname
does not necessarily determine whether a particular request body,
recipient, data classification, operation type, or transaction amount
is authorized.
[0034] A further technical problem arises where a process may access
alternative network interfaces, privileged connectors, host-side
tools, storage services, or hardware paths that are not subject to
the intended mandatory mediation.
[0035] There is therefore a need for protected effectuation-path
coverage that prevents a governed operation from acquiring its
specified consequence through an accessible bypass interface.
7.5. 5. Limits of Model-Level Safety and Computation Admission
[0036] Artificial-intelligence systems may employ input filtering,
output filtering, model classifiers, safety policies, inference-
admission controls, monitoring systems, and human approval
procedures.
[0037] Such mechanisms may reduce the likelihood of unsafe or
unauthorized operations being proposed.
Das Expires 19 April 2027 [Page 55]
Internet-Draft Protected AI Execution Finality October 2026
[0038] However, a model-level safety determination and a downstream
effectuation authorization control different technical events.
[0039] A model may have already generated a consequential tool
request before further inference is interrupted.
[0040] A prepared request may remain buffered in an execution
environment, connector, queue, service, or downstream component even
after the model is prevented from producing further output.
[0041] Consequently, interruption of future model access does not
necessarily prevent a previously generated operation from becoming
effective.
[0042] Nor does successful model-admission authorization establish
that every resulting network request, credential use, persistent
mutation, or external command has been individually authorized.
[0043] A technical need exists for downstream enforcement that
remains effective independently of whether the model is permitted to
continue inference.
7.6. 6. Credential Exposure and Privileged Tool Execution
[0044] AI-agent environments frequently use service credentials, API
keys, access tokens, signing keys, enterprise connectors, and other
privileged mechanisms.
[0045] Credential brokers, secret stores, delegated authorization,
proxy-mediated requests, and privileged service interfaces can
restrict direct exposure of sensitive credentials.
[0046] Nevertheless, credential secrecy and operation authorization
are distinct security properties.
[0047] An agent may be unable to read a protected credential while
still requesting a credential-mediated operation through an
authorized broker.
[0048] The corresponding broker must determine whether the concrete
requested operation falls within the permitted authority.
[0049] Where a credential is released, substituted, applied, or used
to authenticate an operation, the application of that credential may
itself form part of a consequential effectuation sequence.
Das Expires 19 April 2027 [Page 56]
Internet-Draft Protected AI Execution Finality October 2026
[0050] There is therefore a need to bind protected credential use to
the particular authorized operation, destination, execution context,
and effectuation boundary rather than treating access to a credential
broker as unlimited permission to use the corresponding service
identity.
7.7. 7. Delegated AI Agents and Authority Propagation
[0051] Autonomous systems may delegate work to subordinate agents,
tool processes, service workers, or other execution components.
[0052] A delegation may authorize a specified task, tool category,
data scope, execution budget, recursion depth, or time interval.
[0053] However, admission of a delegated task is distinguishable from
authorization of the consequential operations subsequently generated
by the subordinate component.
[0054] A subordinate agent may prepare requests that exceed its
authorized task scope or affect resources requiring separate
execution authority.
[0055] A technical problem therefore arises when general delegated
permissions are implicitly propagated into unrestricted downstream
effectuation authority.
[0056] There is a need for bounded delegation coupled with separate
protected validation of consequential operations generated under that
delegation.
7.8. 8. Time-of-Check and Time-of-Use Vulnerabilities
[0057] In distributed execution systems, the context evaluated during
authorization may differ from the context present when an operation
becomes effective.
[0058] Such differences may arise from changes in the destination,
recipient, request payload, workload identity, policy epoch,
authorization state, executable, tool arguments, route, resource
identifier, or execution environment.
[0059] A previously valid authorization decision may not remain valid
for a materially different operation.
[0060] Similarly, a capability or receipt originally associated with
one operation may be replayed or substituted in an attempt to
authorize another operation.
Das Expires 19 April 2027 [Page 57]
Internet-Draft Protected AI Execution Finality October 2026
[0061] A need therefore exists for deterministic or otherwise
verifiable operation descriptors and effectuation-boundary
comparisons that preserve the relationship between the authorized
operation and the operation actually presented for execution.
7.9. 9. Limitations of Post-Event Monitoring and Audit
[0062] Audit systems and security-monitoring components may record
events, detect anomalies, report violations, or initiate containment.
[0063] Such capabilities are valuable for visibility, accountability,
investigation, and incident response.
[0064] However, evidence generated after a consequential effect does
not retroactively prevent that effect.
[0065] For example, an alert raised after transmission does not
reverse disclosure of data already transmitted.
[0066] Likewise, quarantining an AI workload after an externally
effective operation does not establish that the earlier operation was
prevented.
[0067] A technical need exists for enforcement systems that make the
required validation state a prerequisite to effectuation while
separately preserving monitoring, audit, and post-event containment
functions.
7.10. 10. Distributed State, Replay and Recovery Problems
[0068] AI-agent execution may involve concurrent requests, repeated
operations, communication timeouts, service restarts, workload
migration, virtual-machine snapshots, distributed replicas, and
partial failures.
[0069] In such environments, an execution authorization may be
presented more than once or under a changed operational context.
[0070] A single-use authorization may be consumed by competing
requests if its usage state is not protected by an appropriate
consistency mechanism.
[0071] A restored workload snapshot may contain a previously valid
capability that was subsequently consumed or revoked.
[0072] A communication timeout may occur after a remote service has
already completed an operation.
Das Expires 19 April 2027 [Page 58]
Internet-Draft Protected AI Execution Finality October 2026
[0073] An agent may consequently attempt a retry without knowing
whether the original operation became effective.
[0074] These problems require protected authorization-state
consumption, anti-replay controls, state-version verification,
outcome classification, and recovery conditions distinguishing
pending, reserved, confirmed-effective, denied, and indeterminate
operations.
[0075] Local authorization-state atomicity alone does not guarantee
exactly-once completion at an arbitrary remote service.
[0076] Accordingly, recovery mechanisms should preserve current
protected authority while employing authenticated receiving-side
status, durable idempotency, or other appropriate duplicate-effect
controls where available.
7.11. 11. Confidential Computing and Cryptographic Key Authority
[0077] Confidential virtual machines, trusted execution environments,
hardware security modules, memory-encryption systems, and hardware-
attestation mechanisms provide security properties relating to
computation, memory, measured execution, and cryptographic key
protection.
[0078] However, successful attestation of a workload does not
automatically authorize every consequential operation the workload
may generate.
[0079] Similarly, authority to decrypt protected user information
does not necessarily confer authority to export or disclose that
information.
[0080] A derived key, wrapped key, session-limited key, or protected
credential may enable a bounded cryptographic operation while leaving
separate downstream effectuation authorization unresolved.
[0081] A need therefore exists for architectures separating protected
data-access authority, cryptographic key-use authority, and
operation-specific execution authority.
[0082] There is additionally a need to prevent restoration of a
confidential-VM snapshot from reviving previously consumed or revoked
execution capabilities.
Das Expires 19 April 2027 [Page 59]
Internet-Draft Protected AI Execution Finality October 2026
7.12. 12. Hardware and Accelerator Effectuation Boundaries
[0083] Artificial-intelligence infrastructure increasingly employs
GPUs, TPUs, NPUs, accelerator interconnects, SmartNICs, data
processing units, network fabrics, DMA and RDMA mechanisms, protected
storage controllers, and programmable hardware-enforcement
components.
[0084] These systems may execute transfers and operations at rates
for which repeated high-cost policy evaluation is impractical.
[0085] However, an accelerator's ability to produce an output or
construct a transfer descriptor does not independently establish
authority to release that output into another trust domain.
[0086] Likewise, availability of a network interface does not itself
establish authorization for a particular packet, request,
destination, or transfer.
[0087] A technical need exists for hardware-associated effectuation
controls that permit protected authorization to be evaluated
separately from high-speed transfer admission while requiring the
hardware boundary to enforce the resulting scoped authority.
[0088] Such arrangements may employ protected capability tables,
queue-admission controls, DMA authorization, hardware freshness,
bounded transfer windows, and authenticated control-plane
communication.
7.13. 13. Multi-Boundary and Receiving-Side Enforcement
[0089] A single AI-generated workflow may include several
independently consequential operations.
[0090] These may include model computation, delegated task
acceptance, credential application, network transmission, receiving-
side processing, database commitment, financial settlement, and
physical actuation.
[0091] Authorization at one boundary does not necessarily authorize a
different operation at another boundary.
[0092] In particular, authorization to transmit a request does not
automatically establish authority to execute a receiving-side
database mutation or financial transaction.
Das Expires 19 April 2027 [Page 60]
Internet-Draft Protected AI Execution Finality October 2026
[0093] A technical need therefore exists for architectures that
identify the distinct Finality Sinks involved in a workflow and
require the applicable execution capability to be verified at each
separately governed consequential boundary.
7.14. 14. Earlier Technical Disclosures and Related Applications
[0094] The present technical field includes earlier Indian
provisional and international patent disclosures relating to
cryptographic execution authorization, protected enforcement,
Algorithmic Logic Fingerprinting, and control of irreversible
execution boundaries.
[0095] An Indian provisional application dated 3 January 2026,
entitled Cryptographic Execution-Time Enforcement System with
Purpose- and Jurisdiction-Bound Authorization and Split Execution
Control, describes execution-time control using cryptographically
derived execution handles, execution-scope objects, runtime-verified
Algorithmic Logic Fingerprinting, and enforcement separating
computation from execution authority.
[0096] An Indian provisional application dated 7 January 2026,
entitled Systems and Methods for Cryptographic Enforcement of
Execution Authority at Commit-Time, Settlement-Time, and Other
Irreversible System Boundaries in Distributed, Hardware-Backed
Digital Systems, describes commit-time and settlement-time authority
gates, execution-authority receipts, authority-dependent downstream
execution, controlled persistence, revocation, and fail-closed
enforcement at consequential system boundaries.
[0097] An Indian provisional application dated 12 January 2026,
entitled Systems and Methods for Execution-Time Authorization Using
Multi-Authority, Quantum-Resilient, and Context-Adaptive
Cryptographic Enforcement at Irreversible Execution Boundaries,
describes execution-time authorization using protected multi-
authority conditions, cryptographic execution capabilities, context-
sensitive authority requirements, and enforcement at irreversible
operational boundaries.
[0098] Related international application PCT/IB2026/053385, published
as WO 2026/115520 A2, concerns hardware-enforced cryptographic
execution-time governance using capability withholding, Algorithmic
Logic Fingerprinting, and enforcement at irreversible execution
boundaries.
[0099] Related international applications in the DAS series include:
PCT/IB2026/055615 (DAS Protocols I), published as WO 2026/150382;
Das Expires 19 April 2027 [Page 61]
Internet-Draft Protected AI Execution Finality October 2026
PCT/IB2026/055760 (DAS Protocols II), published as WO 2026/150383 A2;
PCT/IB2026/055870 (DAS Protocols III), published as WO 2026/150384
A2;
PCT/IB2026/056058 (DAS Protocols IV), published as WO 2026/154461 A2;
and
PCT/IB2026/056809 (DAS Protocols V), published as WO 2026/172334 A2.
[0100] These disclosures address different aspects of protected
execution-finality architecture, including agentic execution,
Candidate Act control, authority separation, protected capabilities,
output release, device-side enforcement, and hardware-associated
effectuation.
[0101] The present specification describes further integrated
systems, implementation procedures, alternative embodiments, and
technical mechanisms relating to protected AI-agent execution,
transaction-bound authorization, credential and key-release control,
hardware finality, multi-boundary enforcement, and portable computing
environments.
[0102] References to earlier applications provide technical context.
Any formal priority claim, incorporation by reference, or entitlement
to an earlier effective filing date is governed by the applicable
filing record and legal requirements and is not established merely by
the present description.
7.15. 15. Technical Problem to Be Solved
[0103] Accordingly, there remains a need for a protected execution
architecture capable of permitting autonomous computation while
withholding authority over consequential operations until required
operation-specific validation succeeds.
[0104] More particularly, there is a need for an architecture
providing one or more of the following technical properties:
(a) separation of computation from protected execution authority;
(b) mandatory interception of governed Candidate Acts;
(c) Non-Effective State holding;
(d) canonical operation-specific descriptors;
(e) independent protected authority validation;
Das Expires 19 April 2027 [Page 62]
Internet-Draft Protected AI Execution Finality October 2026
(f) protected grant and authorization-state management;
(g) validation-evidence commitment;
(h) scoped, non-bearer execution-capability release;
(i) independent Finality Sink verification;
(j) credential and cryptographic key-use enforcement;
(k) bounded delegation and agent sandbox control;
(l) multi-agent and multi-boundary effectuation control;
(m) hardware-associated finality enforcement;
(n) runtime monitoring and revocation;
(o) confidential workload and governance-node attestation;
(p) cloud migration and snapshot replay protection; and
(q) crash-consistent recovery with duplicate-effect prevention.
[0105] the proposed architecture addresses these technical problems
through the architecture and embodiments described below.
8. Proposed Technical Architecture
8.1. 16. General Protected Execution-Finality Architecture
[0106] In one aspect, the architecture provides a protected
execution-finality system comprising an AI-Agent Execution
Environment, an operation-interception component, a Candidate Act
staging mechanism, a Protected Enforcement Domain, a protected
authorization-state mechanism, an execution-capability component, and
a Finality Sink.
[0107] The AI-Agent Execution Environment generates, selects,
prepares, stages, or requests a consequential operation.
[0108] The operation-interception component classifies the operation
as a Candidate Act and prevents it from becoming effective through
the governed execution path before completion of the required
protected finality conditions.
Das Expires 19 April 2027 [Page 63]
Internet-Draft Protected AI Execution Finality October 2026
[0109] The Candidate Act may be represented in a Non-Effective State
by a pending request, blocked operation, queued command, inactive
transaction, protected buffer, or equivalent technical arrangement.
[0110] A Candidate Act Descriptor identifies the actual operation and
the finality-relevant context required for authorization.
[0111] The Protected Enforcement Domain obtains or resolves the
applicable Authority Object and validates the Candidate Act against
the required protected authorization predicates.
[0112] The protected system performs any mandatory authorization-
state handling, validation-evidence commitment, and capability-
release conditions.
[0113] Upon successful completion of the applicable protected
prerequisites, a scoped execution capability is released, registered,
activated, or otherwise made available for the authorized operation.
[0114] The designated Finality Sink independently verifies the
applicable capability and protected conditions against the actual
operation before permitting it to become effective.
[0115] If a mandatory condition fails, the governed operation remains
non-effective or is denied.
8.2. 17. Candidate Act and Non-Effective State
[0116] A Candidate Act may comprise any proposed or prepared
operation that would create a governed practical consequence if
permitted to proceed.
[0117] Examples include network transmission, API invocation,
credential application, storage commitment, software deployment,
payment execution, model-state export, accelerator transfer,
protected cryptographic signing, and physical actuation.
[0118] The Non-Effective State separates the computational creation
of the operation from the technical event at which the operation
acquires its governed consequence.
[0119] The operation may be fully computed or ready for execution
while remaining unable to cross the designated effectuation boundary.
[0120] The Non-Effective State may be implemented through protected
queue control, inactive hardware descriptors, controlled service
interfaces, bounded transaction staging, or equivalent enforcement
mechanisms.
Das Expires 19 April 2027 [Page 64]
Internet-Draft Protected AI Execution Finality October 2026
8.3. 18. Canonical Candidate Act Descriptor
[0121] In another aspect, the system constructs a canonical Candidate
Act Descriptor identifying the operation and its required
authorization context.
[0122] The descriptor may comprise one or more of:
(a) operation identifier;
(b) operation class;
(c) requesting workload;
(d) target resource;
(e) destination or recipient;
(f) operation parameters;
(g) payload digest;
(h) execution purpose;
(i) delegated authority;
(j) required runtime measurement;
(k) policy epoch;
(l) protected authorization-state version;
(m) nonce;
(n) validity interval; and
(o) Finality Sink identity.
[0123] The descriptor may be authenticated, hashed, sealed, or
otherwise represented so that materially different effectuation-
relevant operations can be distinguished.
[0124] A Finality Sink may reconstruct the actual operation
descriptor and compare it with the authorized descriptor or its
permitted bounded scope.
[0125] The comparison prevents an authorization for one operation
from being silently substituted for a materially different operation.
Das Expires 19 April 2027 [Page 65]
Internet-Draft Protected AI Execution Finality October 2026
8.4. 19. Protected Enforcement Domain
[0126] The Protected Enforcement Domain comprises a protected
execution, authorization, governance, or enforcement boundary.
[0127] It is isolated from unilateral authority controlled by the
requesting AI agent.
[0128] The PED may perform one or more of:
(a) Authority Object authentication;
(b) execution-scope verification;
(c) workload identity validation;
(d) runtime policy verification;
(e) protected-state updates;
(f) revocation checks;
(g) nonce and freshness validation;
(h) protected validation-evidence commitment;
(i) bounded execution-capability generation; and
(j) fail-closed withholding.
[0129] In selected implementations, the PED may comprise a
Cryptographically Isolated Enforcement Domain providing stronger
protected key custody, integrity, isolation, and rollback-resistance
properties.
[0130] The PED and Finality Sink may be physically separate or
integrated into one protected component, provided that the required
authorization and effectuation-verification functions remain
enforced.
8.5. 20. Transaction-Bound Authorization and Protected State
[0131] In another aspect, the architecture provides protected
authorization-state handling for Candidate Acts.
[0132] An authorization grant may be associated with a permitted
operation, validity interval, remaining usage allowance, nonce,
policy epoch, and revocation state.
Das Expires 19 April 2027 [Page 66]
Internet-Draft Protected AI Execution Finality October 2026
[0133] The protected system prevents unauthorized concurrent
consumption of a single-use grant.
[0134] A protected atomic-state transition may verify and update
grant state, nonce state, capability usage, and authorization-state
references consistently.
[0135] Where required, the authorization-state transition and
validation-evidence commitment form a protected finality transaction.
[0136] An incomplete required transaction cannot produce a valid
usable execution capability.
[0137] The atomicity of protected authorization state is
distinguishable from completion of an arbitrary external operation at
a remote service.
8.6. 21. Protected Validation Evidence
[0138] In another aspect, the system generates or commits protected
validation evidence associated with the Candidate Act.
[0139] The evidence may comprise a LAVR, AVR, authenticated receipt,
sealed authorization commitment, or equivalent protected
representation.
[0140] The evidence may identify the Candidate Act Descriptor,
applicable authority, protected-state transition, policy epoch,
nonce, and designated Finality Sink.
[0141] Where required by the embodiment, the evidence is committed
before, or atomically with, the availability of the corresponding
scoped execution capability.
[0142] Such protected validation evidence is distinguishable from
ordinary post-event logging.
[0143] The protected evidence establishes the specified authorization
conditions; additional completion evidence may be used to establish
whether the consequential operation actually became effective.
8.7. 22. Scoped, Non-Bearer Execution Capability
[0144] Following successful protected authorization, the system makes
available a scoped execution capability.
[0145] The capability is bound to the concrete Candidate Act and
applicable authorization context.
Das Expires 19 April 2027 [Page 67]
Internet-Draft Protected AI Execution Finality October 2026
[0146] Depending upon the embodiment, it may bind operation class,
workload identity, destination, resource scope, protected state,
freshness, policy epoch, receipt commitment, validity interval, usage
count, and Finality Sink identity.
[0147] The capability may comprise a cryptographically signed
artifact, MAC-authenticated permit, sealed execution handle,
protected table entry, hardware enablement condition, or equivalent
mechanism.
[0148] The capability is not treated as unrestricted bearer
authority.
[0149] Its use remains dependent upon verification of the required
operation, state, scope, and Finality Sink bindings.
[0150] Possession of a copy of the capability does not independently
authorize arbitrary replay, substitution, or execution at another
boundary.
8.8. 23. Mandatory Finality Sink Verification
[0151] In another aspect, the Finality Sink verifies the required
execution capability at or immediately before the governed
consequential boundary.
[0152] The verification may include:
(a) capability authenticity;
(b) actual operation correspondence;
(c) permitted execution scope;
(d) recipient or destination;
(e) protected-state validity;
(f) required evidence commitment;
(g) freshness and nonce;
(h) revocation;
(i) usage state; and
(j) designated sink identity.
Das Expires 19 April 2027 [Page 68]
Internet-Draft Protected AI Execution Finality October 2026
[0153] The Finality Sink permits the operation only when all
mandatory predicates succeed.
[0154] Where the Finality Sink governs network transmission, the
enforcement point may be a gateway, egress proxy, NIC, SmartNIC, or
DPU.
[0155] Where the Finality Sink governs persistent modification, it
may be a protected storage or database-commit interface.
[0156] Where the operation involves credentials, the Finality Sink
may be a protected credential broker or controlled service interface.
[0157] Where the operation involves hardware actuation, the Finality
Sink may control the corresponding physical effectuation interface.
8.9. 24. Agent Sandbox and Protected Egress
[0158] In another aspect, an AI-agent runtime operates within a
sandboxed or otherwise restricted execution environment.
[0159] A protected authority outside the unilateral control of the
agent governs selected consequential tool, network, file, and process
operations.
[0160] The system may evaluate executable identity, destination,
resource scope, network protocol, request method, path, payload
attributes, or other specified conditions.
[0161] A requested operation may be classified as an agent sandbox-
egress Candidate Act.
[0162] The PED validates the applicable sandbox-egress Authority
Object and protected policy state.
[0163] Only an authorized operation receives the required scoped
execution capability.
[0164] The protected egress or tool Finality Sink verifies the
capability before permitting the governed effect.
[0165] Runtime policy changes may be subject to protected approval,
policy-version advancement, and revocation handling.
8.10. 25. Credential-Release and Protected Key-Use Finality
[0166] In another aspect, the architecture provides protected
credential-release and credential-use control.
Das Expires 19 April 2027 [Page 69]
Internet-Draft Protected AI Execution Finality October 2026
[0167] An AI agent may refer to a connected service or protected
credential without receiving unrestricted access to the underlying
secret.
[0168] A protected broker or key-use component may maintain the
credential within a protected authority domain.
[0169] The proposed credential-mediated operation is represented by a
Candidate Act Descriptor identifying its actual destination,
operation class, resource, parameters, and applicable authority.
[0170] The PED validates the operation.
[0171] The corresponding protected credential-use or downstream
Finality Sink verifies the required capability before permitting
credential application or the governed external effect.
[0172] A key identifier, credential reference, or successful
authenticated session does not independently authorize unrelated
operations.
8.11. 26. Confidential-VM and User-Controlled Key Authority
[0173] In another aspect, an AI workload executes within an attested
confidential virtual machine.
[0174] Protected user data is encrypted using user-controlled or
user-authorized key material.
[0175] A protected root-key authority may provide bounded derived-
key, wrapped-key, session-limited-key, or controlled cryptographic
access upon satisfaction of required attestation and data-access
conditions.
[0176] Data-access authorization remains distinct from execution-
finality authorization.
[0177] A workload permitted to decrypt or use protected data does not
automatically obtain authority to transmit or otherwise effectuate
that data.
[0178] A proposed consequential operation is separately authorized
and subjected to the required Finality Sink verification.
[0179] Following backup restoration or workload recovery, current
attestation, key-access scope, revocation, and capability-consumption
conditions remain applicable.
Das Expires 19 April 2027 [Page 70]
Internet-Draft Protected AI Execution Finality October 2026
8.12. 27. Multi-Agent Delegation
[0180] In another aspect, the system supports bounded delegation
among AI agents.
[0181] A primary agent may propose delegation of a specified subtask
to a subordinate agent.
[0182] The delegation is evaluated against an applicable Delegation
Authority Object.
[0183] A Delegation Capability may restrict tool classes, data scope,
time window, recursion depth, resource usage, execution budget, or
other conditions.
[0184] Acceptance of the delegation does not independently authorize
later consequential operations generated by the subordinate agent.
[0185] Each separately governed downstream operation remains subject
to its own Candidate Act validation and applicable Finality Sink
verification.
8.13. 28. Model-Path and Downstream Effectuation Separation
[0186] In another aspect, the architecture provides separate controls
for model-computation admission and externally effective operations.
[0187] A model-access component may govern permitted models,
workloads, execution contexts, or inference requests.
[0188] A downstream Candidate Act remains subject to separate
protected authorization.
[0189] A valid model-computation admission record may contribute
authenticated context to downstream authorization without replacing
the downstream execution capability.
[0190] Where an inference request produces streaming or partial tool
operations, the system identifies the consequential unit that
requires protected finality.
[0191] Interruption, denial, or quarantine of further model
computation does not independently authorize release of an already
buffered Candidate Act.
Das Expires 19 April 2027 [Page 71]
Internet-Draft Protected AI Execution Finality October 2026
8.14. 29. Hardware Finality Latch and Accelerator Transfers
[0192] In another aspect, a hardware-associated Finality Sink
controls a consequential transfer or operation.
[0193] The hardware controller may comprise a NIC, SmartNIC, DPU,
GPU, accelerator, FPGA, ASIC, interconnect controller, or protected
storage interface.
[0194] A Hardware Finality Latch prevents admission of the governed
operation until the required scoped capability has been verified.
[0195] The controlled operation may comprise network transmission,
DMA, RDMA, tensor export, accelerator-to-host transfer, accelerator-
to-accelerator transfer, storage commitment, or another protected
interface.
[0196] For streaming transfers, a capability may authorize bounded
transfer windows, units, size limits, routes, memory regions, or
usage allowances.
[0197] The hardware controller verifies applicable freshness and
scope before admitting each required unit or window.
[0198] High-cost authorization may occur through the PED while lower-
cost protected capability verification is performed at the hardware
fast path.
[0199] A performance objective does not eliminate mandatory
enforcement at the governed hardware boundary.
8.15. 30. Hardware Watchdog and Revocation Interlock
[0200] In another aspect, an isolated or out-of-band monitoring
domain generates protected monitoring-state information.
[0201] The information may identify workload identity, monitoring-
state version, validity, and enforcement status.
[0202] The PED may require an acceptable monitoring-state record
before authorizing a consequential Candidate Act.
[0203] The resulting capability may be bound to the required
monitoring-state version.
[0204] A hardware or protected Finality Sink verifies that the
applicable monitoring state remains acceptable before effectuation.
Das Expires 19 April 2027 [Page 72]
Internet-Draft Protected AI Execution Finality October 2026
[0205] Where a security event invalidates required monitoring state,
protected revocation or version advancement causes affected
capabilities to fail subsequent mandatory verification.
[0206] Quarantine may prevent additional governed operations while
preserving the actual completion status of earlier operations.
[0207] The system distinguishes monitoring and post-event containment
from actual pre-effectuation prevention.
8.16. 31. Confidential Governance VM and Hardware-Attested
Effectuation
[0208] In another aspect, protected execution authority is maintained
within a confidential governance virtual machine or separately
protected governance component.
[0209] A hardware-rooted attestation mechanism authenticates the
applicable governance identity and measured execution configuration.
[0210] Protected capability-issuance keys remain isolated from
ordinary AI compute processes.
[0211] The governance component evaluates the Candidate Act against
operation-specific authority.
[0212] A scoped capability may be conveyed through an authenticated
fabric-management communication path to a SmartNIC, DPU, or other
hardware-associated Finality Sink.
[0213] The Finality Sink verifies the required issuing authority,
registered attestation state, actual operation, policy state, and
hardware freshness.
[0214] Invalid mandatory governance attestation or capability state
prevents the governed external transmission.
8.17. 32. Portable Cloud Workloads and Policy-Version Fencing
[0215] In another aspect, an AI workload may execute across
containers, virtual machines, confidential VMs, Kubernetes workloads,
on-premises infrastructure, hybrid clouds, and accelerator-backed
environments.
[0216] An authenticated workload identity and machine-verifiable
execution-context measurement are associated with the applicable
protected authority.
Das Expires 19 April 2027 [Page 73]
Internet-Draft Protected AI Execution Finality October 2026
[0217] The PED maintains authorization-state versions and current
execution-policy predicates.
[0218] A capability is bound to the required workload identity,
Candidate Act, authorization-state version, and Finality Sink.
[0219] Following migration, container replacement, failover, or
snapshot restoration, a pending Candidate Act is revalidated where a
required execution-context condition has changed.
[0220] An incompatible earlier capability is not accepted merely
because the workload's computational state was successfully restored.
[0221] Protected capability-consumption and revocation state remains
authoritative independently of rollback-accessible workload
snapshots.
8.18. 33. Atomic State, Replay Prevention and Recovery
[0222] In another aspect, the system maintains protected grant,
capability, nonce, policy, revocation, and operation-outcome state.
[0223] Required protected authorization-state operations are
performed with the consistency necessary to prevent unauthorized
concurrent consumption.
[0224] A capability bound to a specific Candidate Act, policy epoch,
authorization-state version, nonce, and Finality Sink is rejected
when mandatory state becomes invalid.
[0225] The system distinguishes capability preparation, protected
commitment, capability release, Finality Sink admission, and
confirmed effectuation.
[0226] Following timeout or crash, a retry is correlated with the
original operation identifier.
[0227] Where previous completion is indeterminate, the recovery
mechanism verifies the required duplicate-effect prevention
conditions before permitting another consequential attempt.
[0228] The architecture does not presume that local authorization-
state atomicity establishes exactly-once completion at an unrelated
external system.
Das Expires 19 April 2027 [Page 74]
Internet-Draft Protected AI Execution Finality October 2026
8.19. 34. Multiple Finality Sinks and Receiving-Side Enforcement
[0229] In another aspect, the system classifies operations according
to their effectuation boundaries.
[0230] Distinct operations within a workflow may require
independently enforceable network, tool, credential, storage,
financial, hardware, or physical Finality Sinks.
[0231] A capability authorizing one boundary does not automatically
authorize another.
[0232] A receiving-side Finality Sink may reconstruct the actual
operation and verify the corresponding capability and protected
validation-state commitment.
[0233] Authorization of an upstream network request does not
independently establish authorization of a receiving-side database
commit, payment execution, or physical actuation.
[0234] Each independently governed consequence remains subject to its
applicable protected execution-finality conditions.
8.20. 35. Fail-Closed Handling
[0235] In another aspect, the system refuses effectuation when a
mandatory protected condition is unavailable, invalid, expired,
revoked, replayed, consumed, inconsistent, or unverifiable.
[0236] Failure conditions may include invalid Authority Objects,
stale policy epochs, missing validation receipts, invalid capability
authentication, incompatible runtime measurements, incorrect Finality
Sink identities, exhausted usage limits, unavailable monitoring
state, and failed protected-state commitments.
[0237] A timeout, process crash, communication failure, or hardware
restart does not create unrestricted execution authority.
[0238] Separately authorized emergency, recovery, or Safe-Baseline
operations may be supported where expressly permitted by their
governing authority.
[0239] Such exceptions do not automatically bypass the protected
finality conditions applicable to the original Candidate Act.
Das Expires 19 April 2027 [Page 75]
Internet-Draft Protected AI Execution Finality October 2026
9. Architecture Summary
9.1. 36. General Summary
[0240] the proposed architecture provides systems, methods,
apparatus, and computer-readable instructions for protected
execution-finality control of consequential operations generated by
artificial-intelligence agents and associated computational
environments.
[0241] the architecture separates the ability to compute, prepare,
propose, stage, or route an operation from the protected authority
required to make that operation effective.
[0242] In a principal embodiment, an AI-Agent Execution Environment
generates a Candidate Act.
[0243] A mandatory interception component prevents the Candidate Act
from crossing its governed effectuation boundary while required
execution-finality conditions remain unsatisfied.
[0244] A Candidate Act Descriptor provides a verifiable
representation of the operation and its finality-relevant context.
[0245] A Protected Enforcement Domain independently validates the
applicable Authority Object, operation scope, protected state,
freshness, revocation, and required execution context.
[0246] The protected system performs any mandatory authorization-
state transition and validation-evidence commitment.
[0247] A scoped execution capability is generated, released,
activated, or made available only when the applicable protected
conditions succeed.
[0248] The designated Finality Sink independently verifies the
capability and actual operation before permitting the Candidate Act
to become externally effective.
[0249] Failure of a mandatory condition results in withholding or
denial of the corresponding effect.
9.2. 37. Protected Agent Execution
[0250] In one embodiment, the architecture provides protected
execution for AI agents operating within sandboxed, containerized,
virtualized, or cloud-hosted environments.
Das Expires 19 April 2027 [Page 76]
Internet-Draft Protected AI Execution Finality October 2026
[0251] The system may control tool invocation, network egress, file
operations, executable identity, service access, credential use, or
another effect-capable interface.
[0252] Operation-specific authority is maintained outside the agent's
unilateral control.
[0253] Runtime policy updates, developer approvals, grant revocation,
and usage restrictions may be enforced through protected policy
state.
9.3. 38. Transaction-Bound Credential Control
[0254] In another embodiment, the architecture provides transaction-
bound authorization for credential-mediated operations.
[0255] A protected broker maintains or controls access to the
required credential.
[0256] The concrete operation is represented by a Candidate Act
Descriptor and validated against applicable authority.
[0257] A scoped execution capability is required for protected
credential use or downstream effectuation, according to the governed
boundary.
[0258] The credential is not treated as unrestricted permission for
unrelated operations.
9.4. 39. Protected State and Atomic Finality
[0259] In another embodiment, the system maintains protected
authorization-state records identifying grants, usage allowances,
policy epochs, nonces, revocation state, and capability consumption.
[0260] Required protected-state transitions are performed with the
consistency necessary to prevent unauthorized duplicate consumption.
[0261] Where an atomic finality commitment is required, protected
state and validation-evidence dependencies are satisfied before
capability usability.
[0262] Crash recovery preserves operation-specific authorization
state and distinguishes pending, reserved, confirmed-effective,
denied, and indeterminate operations.
Das Expires 19 April 2027 [Page 77]
Internet-Draft Protected AI Execution Finality October 2026
9.5. 40. Multi-Agent Delegation
[0263] In another embodiment, a primary agent delegates a bounded
task to a subordinate agent.
[0264] Delegation acceptance is governed by a Delegation Authority
Object and corresponding protected capability.
[0265] Consequential operations generated under the delegation remain
subject to their own protected execution-finality conditions.
[0266] Delegated computation does not create unrestricted downstream
effectuation authority.
9.6. 41. Model-Path and Effectuation-Path Separation
[0267] In another embodiment, the system separately governs model-
computation admission and downstream consequential operations.
[0268] Successful model admission does not independently authorize
operations generated by the model.
[0269] A model-generated tool request, network transmission, storage
mutation, payment, or other governed operation is subjected to
separate Candidate Act authorization and Finality Sink verification.
[0270] Interruption of future model access does not automatically
release an already buffered Candidate Act.
9.7. 42. Hardware-Assisted Finality
[0271] In another embodiment, the Finality Sink comprises a hardware-
associated controller.
[0272] The controller may include a NIC, SmartNIC, DPU, accelerator
controller, FPGA, ASIC, protected memory interface, or other suitable
hardware mechanism.
[0273] A Hardware Finality Latch prevents the governed operation from
becoming effective until the required capability verifies.
[0274] The arrangement may control network transmission, DMA, RDMA,
accelerator transfer, storage commitment, or another hardware
effectuation boundary.
[0275] Hardware freshness and protected capability-consumption state
may prevent unauthorized replay.
Das Expires 19 April 2027 [Page 78]
Internet-Draft Protected AI Execution Finality October 2026
9.8. 43. Confidential Governance and Key Authority
[0276] In another embodiment, protected authorization operates within
an attested confidential governance environment.
[0277] Governance key material remains protected against unrestricted
access by ordinary AI compute processes.
[0278] An authenticated capability is released following operation-
specific validation and may be conveyed to a hardware-associated
Finality Sink.
[0279] The Finality Sink verifies the required issuer attestation,
operation context, protected state, and execution scope before
effectuation.
[0280] In another embodiment, user-controlled root-key material
enables bounded protected data access without independently
authorizing external disclosure or other consequential operations.
9.9. 44. Monitoring and Revocation
[0281] In another embodiment, an isolated monitoring domain supplies
authenticated workload-monitoring state.
[0282] The PED evaluates the required monitoring condition when
authorizing a Candidate Act.
[0283] A scoped capability may be bound to the corresponding
monitoring-state version.
[0284] Revocation or invalidation of mandatory monitoring state
causes affected subsequent operations to fail the required Finality
Sink verification.
[0285] Quarantine and recovery procedures preserve the actual
effectuation status of earlier operations.
9.10. 45. Cross-Cloud Portability
[0286] In another embodiment, the AI workload executes across
multiple cloud, container, virtual-machine, and accelerator
environments.
[0287] The system authenticates the workload identity and required
execution-context measurement.
Das Expires 19 April 2027 [Page 79]
Internet-Draft Protected AI Execution Finality October 2026
[0288] Protected authorization-state versions are maintained across
affected workload scopes.
[0289] Migration, failover, or snapshot recovery does not
automatically restore stale, consumed, or revoked execution
authority.
[0290] Pending consequential operations are revalidated when the
required execution context changes.
9.11. 46. Independent Downstream Finality
[0291] In another embodiment, a workflow comprises multiple
consequential operations associated with different Finality Sinks.
[0292] Each governed operation receives authorization appropriate to
its own effectuation boundary.
[0293] A receiving-side Finality Sink reconstructs or verifies the
actual operation before permitting a separately governed downstream
consequence.
[0294] An authorization to communicate, delegate, infer, or invoke an
upstream service does not independently grant authority over a
receiving-side database, payment, storage, or hardware operation.
9.12. 47. Technical Advantages
[0295] Depending upon the particular embodiment and implemented
protection mechanisms, the architecture may provide one or more of
the following technical effects:
(a) separation of computation from protected execution authority;
(b) prevention of unauthorized consequential operations at controlled
effectuation boundaries;
(c) reduced opportunity for unauthorized operation substitution;
(d) protected capability scope and replay control;
(e) protected grant consumption and authorization-state consistency;
(f) bounded credential and cryptographic key use;
(g) enforced limits on delegated AI-agent operations;
(h) separation of model computation from downstream effectuation;
Das Expires 19 April 2027 [Page 80]
Internet-Draft Protected AI Execution Finality October 2026
(i) hardware-enforced network and accelerator admission;
(j) monitoring-state-dependent revocation;
(k) attestation-bound confidential governance;
(l) independent receiving-side authorization;
(m) protection against stale authority after migration or snapshot
restoration;
(n) improved recovery handling for indeterminate operation outcomes;
and
(o) authenticated evidence of protected execution-finality decisions.
[0296] The foregoing technical effects depend upon the enforcement
interfaces, protected trust boundaries, mandatory predicates, and
state mechanisms implemented in a particular embodiment.
[0297] No single embodiment is required to include every component or
alternative described herein unless expressly required under the
specified enforcement profile.
9.13. 48. General Inventive Principle
[0298] the architecture establishes a protected causal dependency
between generation of a consequential operation and the authority
required to make that operation effective.
[0299] The requesting computational environment may generate or
prepare an operation, but cannot independently confer the required
protected execution authority.
[0300] The operation remains non-effective until its applicable
protected authorization conditions succeed.
[0301] A scoped execution capability provides the required operation-
specific execution enablement.
[0302] The Finality Sink verifies that enablement against the actual
operation before permitting its governed consequential effect.
[0303] the architecture thereby provides an architecture in which
computation and execution authority are technically distinguishable
and in which required protected authority is enforced at the actual
consequence-producing boundary.
Das Expires 19 April 2027 [Page 81]
Internet-Draft Protected AI Execution Finality October 2026
Computation is not authority to act.
10. Terminology and Definitions
10.1. 1. AI-Agent Execution Environment
“AI-Agent Execution Environment” means an artificial-intelligence
model, autonomous or semi-autonomous agent, tool-using model,
planner, orchestrator, application, software process, container,
virtual machine, cloud workload, or associated computing environment
that generates, requests, prepares, stages, or processes a Candidate
Act.
The environment may perform computation and prepare operations but
does not independently obtain authority to make a governed Candidate
Act externally effective without satisfying the applicable protected
execution-finality conditions.
10.2. 2. Proposed Operation and Candidate Act
“Candidate Act” means any proposed, requested, generated, computed,
derived, staged, buffered, prepared, simulated, selected, planned,
delegated, sequenced, scheduled, conditionally generated, or
otherwise pending operation that, if permitted to proceed, would
produce an externally effective, operationally effective, network-
effective, data-effective, model-effective, financially effective,
legally effective, physically effective, or machine-effective
consequence.
A Candidate Act may include a tool invocation, API request, network
transmission, storage commit, payment instruction, deployment, model
update, or physical actuation, including applicable governed omission
or non-renewal events.
10.3. 3. Externally Effective Operation
“External Effectuation” means the transition of a Candidate Act from
a Non-Effective State into a state of practical consequence.
Such consequence may be physical, logical, network, financial, legal,
operational, computational, cryptographic, data-related, radio,
optical, memory-related, content-related, actuator-related, or cyber-
physical.
External Effectuation does not require an operation to leave the
physical device or system. An internal memory write, model update,
signing event, register activation, tool execution, or other
consequential state transition may constitute External Effectuation.
Das Expires 19 April 2027 [Page 82]
Internet-Draft Protected AI Execution Finality October 2026
10.4. 4. Non-Effective State (NES)
“Non-Effective State” means a technical state in which a Candidate
Act has been generated, proposed, computed, buffered, prepared,
staged, sealed, encrypted, queued, or otherwise made available within
a system but has not become externally effective or otherwise
acquired its governed practical consequence.
“Non-Final State” expresses the corresponding condition before
completion of the applicable finality decision.
A Pending State is a form of Non-Effective State in which the
Candidate Act awaits required validation, protected-state handling,
evidence commitment, capability release, or Finality Sink
verification.
10.5. 5. Mandatory Interception and Mediation
“Mandatory Interception and Mediation” refers to the enforcement
arrangement by which a governed Candidate Act is subjected to the
applicable protected execution-finality controls before crossing its
governed effectuation boundary.
The operation may be held, denied, deferred, or permitted according
to the required authorization conditions. A Non-Authoritative
Mediator may prepare or route the operation but cannot independently
supply the protected execution authority required for effectuation.
10.6. 6. Execution-Finality Boundary
“Execution-Finality Boundary” refers to a Finality Boundary at or
before which a Candidate Act would first become externally effective,
operationally binding, practically usable, transmitted, rendered,
committed, stored, settled, decrypted, signed, actuated, emitted,
admitted, or otherwise consequential unless blocked.
The boundary may be implemented at a network, storage, settlement,
rendering, cryptographic-signing, computation-admission, output-
release, or physical-actuation interface according to the applicable
embodiment.
10.7. 7. Finality Sink
“Finality Sink” means the technical effectuation boundary at which a
Candidate Act would first become externally effective, practically
usable, transmitted, committed, rendered, actuated, settled, stored,
decrypted, signed, emitted, forwarded, admitted, energized, or
otherwise given practical effect.
Das Expires 19 April 2027 [Page 83]
Internet-Draft Protected AI Execution Finality October 2026
The Finality Sink is distinct from the Finality Gate. Where the
embodiment requires a scoped non-bearer capability, the Finality Sink
verifies that capability and permits the finalizing operation only
upon successful verification.
Finality Gate: A protected technical enforcement mechanism positioned
at, immediately before, or in non-bypassable control of a Finality
Boundary, configured to determine whether a Candidate Act may cross
that boundary by performing or enforcing protected validation and
controlling the release, use, withholding, or denial of the required
scoped execution capability.
10.8. 8. Protected Enforcement Domain (PED) and Cryptographically
Isolated Enforcement Domain (CIED)
“Protected Enforcement Domain” (PED) means a protected execution,
authority, governance, or enforcement boundary configured to perform
protected finality functions before a Candidate Act becomes
externally effective.
Such functions may include authority validation, protected-state
handling, validation-evidence commitment, capability release, and
fail-closed withholding.
“Cryptographically Isolated Enforcement Domain” (CIED) means a
stronger species of PED providing cryptographic isolation, protected
key control, validation-logic integrity, protected mutable state, and
associated resistance to unauthorized tampering, rollback, replay, or
bypass.
Every CIED may be a PED; not every PED must satisfy the stronger CIED
requirements.
10.9. 9. Protected Isolation from Agent Control
“Protected Isolation from Agent Control” refers to the separation of
required validation logic, protected authorization state, and
execution-capability release authority from unilateral control by the
requesting AI agent or other non-authoritative component.
The agent may propose operations, supply evidence, or request
authorization but cannot independently override the protected
validation and capability-release conditions.
The isolation guarantees depend upon the applicable PED, CIED,
hardware, firmware, software, or other protected enforcement
implementation.
Das Expires 19 April 2027 [Page 84]
Internet-Draft Protected AI Execution Finality October 2026
10.10. 10. Non-Bypassable Governed Execution Path
“Non-Bypassable Governed Execution Path” refers to an execution
arrangement in which the applicable Finality Gate and Finality Sink
control the governed effectuation interface so that a Candidate Act
cannot obtain its specified consequential effect through that
interface without satisfying the required protected finality
conditions.
The path may include host, network, storage, application, hardware,
or downstream enforcement components.
The non-bypassable property applies to the effectuation paths covered
by the particular implementation and its specified enforcement
requirements.
10.11. 11. Finality Sink Verification
“Finality Sink Verification” means verification performed by a
Finality Sink before effectuation to determine whether the required
scoped non-bearer capability and its applicable Candidate Act,
descriptor, validation-evidence, protected-state, freshness, policy,
and sink-specific bindings are valid.
Where the relevant embodiment requires such verification, the
Finality Sink refuses effectuation if a mandatory capability or
binding condition is absent, invalid, expired, revoked, replayed,
consumed, or mismatched.
Finality Sink Verification is a distinct functional requirement but
does not necessarily require a physically separate component from the
Protected Enforcement Domain or Finality Gate.
10.12. 12. Fail-Closed Enforcement
“Fail-Closed Enforcement” means an execution-control property under
which failure, absence, unavailability, inconsistency, expiry,
revocation, or unsuccessful verification of a required protected
authorization condition does not permit the governed Candidate Act to
become externally effective.
A timeout, crash, restart, communication failure, unavailable
protected state, or enforcement-component failure does not create
execution authority.
An embodiment may permit separately authorized emergency, recovery,
or Safe-Baseline operations without granting unrestricted permission
to the original Candidate Act.
Das Expires 19 April 2027 [Page 85]
Internet-Draft Protected AI Execution Finality October 2026
10.13. 13. Authority Object
“Authority Object” means a signed, MAC-protected, attested, sealed,
quorum-approved, regulator-issued, operator-issued, enterprise-
issued, TEE-issued, HSM-issued, machine-verifiable, or protected-
domain-controlled object defining permitted scope, conditions,
validity, revocation state, policy epoch, jurisdiction, purpose,
target boundary, receipt requirement, or equivalent authorization
context for one or more Candidate Acts.
The term includes applicable specialized authority objects, including
EASO, delegated authority objects, Self-Mutation Authority Objects,
Sandbox Egress Authority Objects, Supply-Chain Authority Objects, and
other forms expressly described in the corresponding embodiments.
Possession of an Authority Object does not independently establish
satisfaction of the required protected execution-finality conditions.
10.14. 14. Candidate Act Descriptor (CAD)
“Candidate Act Descriptor” (CAD) means a canonical, deterministic,
machine-readable, protected, cryptographic, or otherwise verifiable
representation of a Candidate Act and its finality-relevant context
before that Candidate Act becomes externally effective.
A CAD may represent the act class, effect class, target boundary,
destination, authority conditions, runtime context, policy epoch,
freshness, nonce, receipt requirement, Finality Sink identity,
permitted scope, or other information required for protected
authorization.
A Hash-Linked Candidate Act Descriptor (HCAD) is a specialized
descriptor incorporating applicable cryptographic linkage or
commitments.
The descriptor is distinguishable from the Candidate Act itself.
10.15. 15. Canonical Descriptor and Equality Verification
“Canonical Descriptor and Equality Verification” refers to
deterministic representation and machine-verifiable comparison of a
Candidate Act against its applicable authorized descriptor,
commitment, or permitted execution scope.
Canonicalization may include field ordering, type normalization,
identifier normalization, destination normalization, encoding
normalization, payload hashing, and binding to authority, freshness,
policy, and Finality Sink context.
Das Expires 19 April 2027 [Page 86]
Internet-Draft Protected AI Execution Finality October 2026
Equivalent acts may produce corresponding canonical representations
under the applicable rules, while materially different acts remain
distinguishable.
Verification may require exact descriptor correspondence or
satisfaction of defined bounded-scope predicates. The requesting
agent cannot independently authorize operation substitution.
10.16. 16. Authority Predicate and Protected Authorization Predicate
“Authority Predicate” means a machine-evaluable condition,
credential, claim, token, certificate, descriptor, proof,
attestation, state value, policy value, cryptographic commitment, or
equivalent condition required for authorization of a Candidate Act.
Such predicates may concern identity, purpose, jurisdiction,
validity, revocation, nonce, quota, policy epoch, ALF, AIF, RBD,
attestation, human approval, authority quorum, Finality Sink
identity, or protected-state consistency.
“Protected Authorization Predicate” refers to an Authority Predicate
evaluated or enforced through the applicable protected authorization
mechanism.
Only the predicates required by the corresponding embodiment are
mandatory.
10.17. 17. Authorized Purpose and Execution Scope
“Authorized Purpose” means the permitted operational purpose or
objective applicable to a Candidate Act.
“Execution Scope” means the bounded operations, resources,
destinations, purposes, time intervals, usage conditions, and
execution contexts within which the Candidate Act may receive
execution authority.
An Authorized Intent Envelope or Execution Authorization Scope Object
(EASO) may define these conditions.
Under the disclosed AIF matching rule, a Candidate Intent Descriptor
may be authorized when equal to, narrower than, or contained within
the Authorized Intent Envelope.
An agent cannot independently widen the applicable authorized scope.
Das Expires 19 April 2027 [Page 87]
Internet-Draft Protected AI Execution Finality October 2026
10.18. 18. Protected Validation Evidence
“Protected Validation Evidence” means a protected validation record,
receipt, commitment, signature, sealed record, hash-chain entry,
Merkle commitment, LAVR, denial receipt, failure receipt, or
equivalent machine-verifiable evidence recording or establishing that
required protected validation occurred, was attempted, or produced a
specified result.
Where the applicable embodiment requires evidence commitment as a
prerequisite to capability release, that commitment is established
before, or atomically with, capability availability.
Protected Validation Evidence is distinct from the Authority Object,
Candidate Act Descriptor, protected state, scoped execution
capability, and Finality Sink.
10.19. 19. Ledger-Anchored Validation Receipt (LAVR) and Egress LAVR
“Ledger-Anchored Validation Receipt” (LAVR) means a cryptographically
signed or otherwise protected, tamper-evident validation artifact
generated by, within, or under control of a Protected Enforcement
Domain at or immediately before a Finality Boundary.
It records the applicable Candidate Act or governed event,
authorization context, validation outcome, and associated protected
evidence.
A LAVR may use sealed storage, append-only records, hash chains,
Merkle commitments, or ledger anchoring, as supported by the
embodiment.
“Egress LAVR” means a LAVR associated with a governed egress
operation, including the Sandbox Egress Finality Gate embodiment. A
required Egress LAVR does not itself replace Sandbox Egress
Capability verification.
10.20. 20. Zero-Knowledge Ledger-Anchored Validation Receipt (ZK-LAVR)
“Zero-Knowledge Ledger-Anchored Validation Receipt” (ZK-LAVR) means a
protected validation receipt configured to establish, through a zero-
knowledge proof or supported privacy-preserving verification
mechanism, that required execution-finality predicates were satisfied
without disclosing specified underlying protected information.
Such information may include AIF, ALF, RBD, biometric state, private
context, model configuration, enterprise policy, or confidential
workflow information.
Das Expires 19 April 2027 [Page 88]
Internet-Draft Protected AI Execution Finality October 2026
Supported implementations may include zero-knowledge proof systems or
hybrid attestation-based constructions. The formal zero-knowledge
guarantee depends upon the actual proof mechanism.
A ZK-LAVR is validation evidence, not an unrestricted execution
capability.
10.21. 21. Protected Evidence Commitment and Ordering
“Protected Evidence Commitment and Ordering” refers to the protected
execution-finality relationship under which required validation
evidence and corresponding protected-state operations are committed
before, or atomically with, availability of the applicable scoped
non-bearer capability.
Such commitment may comprise a LAVR, sealed record, cryptographic
commitment, protected-state reference, or equivalent protected
validation evidence.
Capability availability remains dependent upon successful completion
of the required validation and commitment operations. Evidence
commitment does not require immediate public or external ledger
publication.
10.22. 22. Scoped Execution Capability
“Scoped Execution Capability” means a protected-domain-issued,
protected-domain-controlled, or protected-domain-dependent technical
execution-enabling condition required for a governed Candidate Act to
become effective within its Permitted Effectuation Scope.
The capability may comprise a cryptographic artifact, protected key,
sealed handle, authenticated execution permit, hardware-enable
condition, or equivalent protected mechanism.
It may be bound to the Candidate Act, descriptor, authorization
scope, protected state, validation receipt, freshness condition, or
Finality Sink as required by the applicable embodiment.
10.23. 23. Non-Bearer Capability
“Non-Bearer Capability” means a scoped execution-enabling capability
whose possession, copying, transmission, storage, forwarding, replay,
or presentation does not independently confer authority to effectuate
a Candidate Act.
Its use remains subject to the applicable protected authorization,
scope, state, and Finality Sink verification requirements.
Das Expires 19 April 2027 [Page 89]
Internet-Draft Protected AI Execution Finality October 2026
A Non-Bearer Capability may be act-bound, descriptor-bound, sink-
bound, time-bound, nonce-bound, receipt-bound, or protected-state-
bound.
Non-bearer status does not necessarily require physical non-
copyability, single-use operation, or a particular hardware
implementation unless expressly specified.
10.24. 24. Human Approval and Approval Artifact
“Human Approval” means an authorization decision supplied by a human
actor having the authority required for a particular Candidate Act or
governed operation.
“Approval Artifact” means a machine-verifiable representation of that
decision, which may identify the approver, authorized role, Candidate
Act or permitted operation class, decision, validity period, approval
scope, and applicable policy conditions.
Where required, Human Approval is an Authority Predicate validated by
the Protected Enforcement Domain.
Human Approval does not independently substitute for required
protected validation, evidence commitment, capability release, or
Finality Sink verification.
10.25. 25. Protected Policy State and Policy Epoch
“Protected Policy State” means policy-related authorization
information maintained, authenticated, validated, or controlled
within an applicable protected enforcement mechanism and used to
determine the permitted execution conditions of Candidate Acts.
“Policy Epoch” means a bounded version, generation, time interval,
authority-controlled state, registry version, or protected rule-set
state associated with applicable authorization or governance rules.
A Candidate Act or execution capability may be bound to the relevant
Policy Epoch.
Where current epoch verification is required, an invalid or
superseded policy state does not independently authorize
effectuation.
Das Expires 19 April 2027 [Page 90]
Internet-Draft Protected AI Execution Finality October 2026
10.26. 26. Runtime Execution Context
“Runtime Context” means measured, observed, attested, sampled,
reported, sealed, or otherwise machine-verifiable execution
circumstances under which a Candidate Act is generated, processed,
validated, or prepared for effectuation.
Such circumstances may include model, software, hardware, process,
enclave, network, memory, queue, controller, tool, retrieval, policy,
sensor, route, or timing state.
“Runtime Execution Context” refers to the subset of those
circumstances relevant to the applicable protected authorization and
Finality Sink verification.
Runtime Context is distinguishable from Authority Context and Purpose
Context.
10.27. 27. Nonce, Freshness, and Expiry
“Nonce” means a value used within an applicable authorization or
execution-finality procedure to distinguish an operation,
authorization event, session, or protected state and support required
replay-prevention or freshness conditions.
“Freshness” refers to the verified current validity of an
authorization artifact, protected state, policy epoch, nonce,
timestamp, sequence, or other required execution condition.
“Expiry” refers to termination of validity under the applicable
temporal or protected-state restriction.
Where required freshness cannot be established or validity has
expired, the corresponding execution capability is withheld or
rejected under the applicable fail-closed conditions.
10.28. 28. Revocation
“Revocation” means an authorized withdrawal, cancellation,
invalidation, or termination of previously established execution
authority, an Authority Object, credential, approval, capability,
policy authorization, or other protected governance condition.
“Revocation-Aware Enforcement” requires verification that the
relevant authority remains non-revoked at the execution-time boundary
specified by the embodiment.
Das Expires 19 April 2027 [Page 91]
Internet-Draft Protected AI Execution Finality October 2026
Revocation may be represented by protected revocation state,
revocation epochs, authenticated status records, or equivalent
mechanisms.
Where current non-revocation is mandatory, stale, unavailable,
inconsistent, or unverifiable revocation information does not
establish authority to proceed.
10.29. 29. Capability Consumption
“Capability Consumption” means marking, retiring, consuming,
invalidating, or cryptographically advancing a scoped non-bearer
capability after a permitted finality event or attempted finality
event, as specified by the applicable embodiment.
Consumption may be bound to the Candidate Act or HCAD digest,
Finality Sink, LAVR digest, nonce, policy epoch, validity window,
capability sequence number, or protected governance-chain state.
A consumed single-use capability cannot authorize another
effectuation contrary to its permitted scope.
Capabilities expressly permitting bounded multiple uses remain
subject to their specified usage and protected-state restrictions.
10.30. 30. Atomic Protected-State Transition
“Atomic Protected-State Transition” refers to a protected enforcement
operation in which required authorization-state updates are performed
with the consistency and ordering necessary to prevent unauthorized
effectuation resulting from incomplete or inconsistent protected-
state handling.
Under the disclosed Atomic State Consumption and Atomic Finality
Commit mechanisms, required validation, state consumption or update,
validation-evidence commitment, and capability availability are
coordinated as one protected finality transaction.
Where atomic commitment is required, the relevant sub-operations
commit together or fail together. A failed mandatory transaction
cannot produce a usable execution capability.
The mechanism does not necessarily require a single globally
distributed database transaction.
Das Expires 19 April 2027 [Page 92]
Internet-Draft Protected AI Execution Finality October 2026
10.31. 31. Formal Candidate Act State Machine
“Formal Candidate Act State Machine” means a bounded execution-
finality state machine defining the permitted states and transitions
of a Candidate Act before and during governed effectuation.
Non-limiting states include Non-Final, Descriptor-Pending,
Descriptor-Formed, Validation-Pending, Validation-Failed, Held,
Quarantined, Escalated, Capability-Prepared, Capability-Released,
Sink-Verified, Released, Denied, Revoked, Expired, and Zeroized.
Transition to Released requires satisfaction of the applicable
protected validation, state-handling, evidence-commitment,
capability-release, and Finality Sink verification conditions.
Capability preparation or release alone does not constitute external
effectuation.
10.32. 32. Replay and Unauthorized Reuse
“Anti-Replay Protection” means technical measures intended to prevent
unauthorized reuse of a previously issued authorization artifact,
governance artifact, protected validation receipt, scoped execution
capability, or release approval.
Such measures may include nonce verification, freshness checks,
temporal validity, session binding, challenge-response verification,
protected counters, capability consumption, governance-chain linkage,
or protected-state advancement.
An artifact previously valid for one Candidate Act, execution
context, Finality Sink, or authorized usage condition does not
independently authorize its reuse outside the permitted scope.
10.33. 33. Duplicate External Effect Prevention
“Duplicate External Effect Prevention” refers to protected
enforcement measures configured to prevent a governed Candidate Act
from producing an additional consequential effect through
unauthorized repetition, replay, retry, capability reuse, or
duplicate submission.
Such measures may employ capability-consumption state, protected
nonces, operation identifiers, sink-specific usage records, monotonic
counters, or equivalent protected state.
Where single-effect authorization is required, the same consumed
authorization cannot validly enable another effectuation event.
Das Expires 19 April 2027 [Page 93]
Internet-Draft Protected AI Execution Finality October 2026
This definition does not independently guarantee exactly-once
delivery or completion across every external system.
10.34. 34. Crash, Retry, and Recovery
“Crash, Retry, and Recovery” refers to the protected handling of
interrupted, failed, restarted, repeated, or restored execution-
finality operations.
A crash, timeout, restart, communication failure, interrupted
commitment, or recovery-mode transition does not independently grant
authority to effectuate a Candidate Act.
Where required, recovery preserves or re-establishes the applicable
protected authorization state, evidence commitment, capability-
consumption status, policy epoch, and Finality Sink verification
conditions.
An operation with uncertain completion status is not automatically
authorized for another consequential execution. Recovery-only
actions remain subject to their applicable protected authorization
conditions.
10.35. 35. Audit Evidence
“Audit Evidence” means a record, event, log, receipt, trace,
commitment, or other machine-readable information documenting an
operation, validation event, authorization decision, protected-state
transition, denial, capability event, or effectuation outcome.
Audit Evidence may be generated before, during, or after an
operation.
Ordinary post-event logging does not independently constitute
Protected Validation Evidence or satisfy a required pre-effectuation
commitment.
Where an embodiment requires validation evidence as a prerequisite to
capability release, the required protected evidence must participate
in the execution-finality dependency rather than merely document the
completed operation afterward.
Das Expires 19 April 2027 [Page 94]
Internet-Draft Protected AI Execution Finality October 2026
10.36. 36. Bounded-Time and Latency-Aware Enforcement
“Bounded-Time and Latency-Aware Enforcement” refers to execution-
finality arrangements in which protected authorization processing and
Finality Sink verification are organized to satisfy applicable timing
or performance constraints without removing mandatory authorization
dependencies.
Computationally intensive validation may occur at protected control
points, while a Finality Sink performs compact, locally verifiable
capability checks on a latency-sensitive path.
Supported mechanisms may include protected caching, bounded
capability windows, precomputed commitments, hardware verification,
and batched validation.
The applicable implementation determines actual timing guarantees.
Latency optimization does not authorize a Candidate Act to bypass
required finality verification.
10.37. 37. Algorithmic Logic Fingerprint (ALF)
“Algorithmic Logic Fingerprint” (ALF) means a machine-verifiable
logic-measurement artifact, fingerprint, digest, structural
identifier, semantic identifier, logic-bound signature, approval
artifact, measurement value, class identifier, or equivalent
construct associated with Algorithmic Logic.
An ALF may represent an approved model, computational workflow, tool
graph, retrieval policy, orchestration configuration, runtime
pipeline, transformation logic, or policy configuration.
ALF validation determines whether the relevant logic or configuration
corresponds to an approved condition at the applicable computation-
admission, runtime, or execution-finality stage.
ALF validation is an authorization predicate and does not
independently constitute final execution authority.
10.38. 38. Algorithmic Intent Fingerprint (AIF)
“Algorithmic Intent Fingerprint” (AIF) means a machine-verifiable
representation of the bounded operational intent under which a
Candidate Act is permitted to proceed.
An AIF may represent authorized purpose, operation class, tool scope,
data scope, destination, resource, jurisdiction, delegation,
transaction limits, or other permitted operational conditions.
Das Expires 19 April 2027 [Page 95]
Internet-Draft Protected AI Execution Finality October 2026
A Candidate Intent Descriptor may satisfy the Authorized Intent
Envelope through exact correspondence or permitted subset
containment.
AIF represents authorized operational purpose and scope, not an
artificial-intelligence model's subjective psychological intent. It
is distinct from ALF, which governs approved computational logic.
10.39. 39. Runtime Behavioral Descriptor (RBD)
“Runtime Behavioral Descriptor” (RBD) means a bounded machine-
verifiable representation of governance-relevant behavior observed
during a particular execution or invocation.
An RBD may represent tools invoked, resources accessed, documents
read, applications accessed, APIs called, external content consumed,
sub-agents spawned, permissions requested, connector usage, policy
branches, runtime measurements, and output class.
The RBD may be evaluated against approved logic, operational intent,
protected policy, or other applicable execution-finality predicates.
It need not disclose hidden model reasoning. RBD validation does not
independently substitute for required capability issuance or Finality
Sink verification.
10.40. 40. Tool and Workflow Graph
“Tool and Workflow Graph” refers to a machine-representable structure
identifying tools, computational operations, workflow stages,
orchestration relationships, retrieval paths, execution dependencies,
or permitted transitions associated with an AI-agent or computational
process.
Such a graph may be included in, referenced by, or cryptographically
bound to an Algorithmic Logic Fingerprint, approved workflow
configuration, or applicable Authority Object.
Where graph authorization is required, a materially changed tool or
workflow configuration must satisfy the corresponding protected
validation conditions before a governed Candidate Act becomes
effective.
The graph is not itself an execution capability.
Das Expires 19 April 2027 [Page 96]
Internet-Draft Protected AI Execution Finality October 2026
10.41. 41. Provenance and Taint
“Provenance” refers to machine-verifiable information concerning the
source, origin, lineage, transformation, or influence of data,
instructions, tool outputs, or other material contributing to a
Candidate Act.
“Taint” refers to a trust classification or restriction associated
with content or execution context originating from an untrusted or
lower-trust source.
Provenance and taint information may be represented through protected
descriptors, Connector Boundary Receipts, Instruction Taint Boundary
Objects, or equivalent records.
Such information may be evaluated as an authorization predicate.
Untrusted content does not independently acquire authority to control
tool execution, policy, memory, or external effectuation.
10.42. 42. Untrusted Input Influence
“Untrusted Input Influence” refers to the contribution or attempted
contribution of lower-trust information to an AI-generated
instruction, decision, tool invocation, workflow modification, or
Candidate Act.
Such information may originate from retrieved documents, webpages,
emails, tool responses, memory entries, files, or external data
sources.
An Instruction Taint Boundary Object (ITBO) may distinguish trusted
instructions from untrusted content and restrict the promotion of
evidence into execution authority.
Where required, the protected enforcement mechanism validates the
resulting Candidate Act independently of instructions contained in
untrusted material.
10.43. 43. Self-Mutation
“Self-Mutation” refers to an AI-agent-initiated or computationally
generated modification of its model runtime, system prompt, tool-
access policy, safety configuration, retrieval connector, memory
policy, delegation policy, planner policy, adapter state, or workflow
graph.
The proposed modification may constitute a Candidate Self-Mutation
Act.
Das Expires 19 April 2027 [Page 97]
Internet-Draft Protected AI Execution Finality October 2026
In the Self-Modification Finality Gate embodiment, the act remains
non-effective until the PED validates the applicable Self-Mutation
Authority Object and releases the required Self-Modification
Capability.
The corresponding activation boundary verifies the capability before
making the modification effective.
10.44. 44. Delegation
“Delegation” refers to a proposed transfer or assignment of a task,
subtask, execution function, tool access, data access, memory access,
workflow responsibility, or bounded authority from one agent or
component to another.
A governed delegation constitutes a Candidate Delegation Act.
Where protected delegation finality is required, the PED validates
the applicable Delegation Authority Object and releases a scoped
Delegation Capability.
The receiving agent or downstream workflow verifies the capability
before accepting the governed delegation.
Delegation does not independently enlarge the authority originally
available to the delegating agent.
10.45. 45. Delegation Limits
“Delegation Limits” refers to the restrictions applicable to
authority delegated to a subordinate agent, specialist agent, tool
agent, or downstream workflow.
Such restrictions may include parent and child agent identities,
delegated objective, permitted subtask, tool class, data scope,
memory scope, time window, recursion depth, execution budget,
prohibited operations, policy epoch, revocation state, and freshness
conditions.
Where the applicable embodiment requires these restrictions, the
Delegation Authority Object and Delegation Capability bind the
permitted delegated scope.
An operation exceeding a mandatory delegation limit requires separate
valid authority before effectuation.
Das Expires 19 April 2027 [Page 98]
Internet-Draft Protected AI Execution Finality October 2026
10.46. 46. Candidate Deployment Act
“Candidate Deployment Act” means a proposed operation involving
source-code merge, repository modification, build or CI/CD
configuration, dependency update, package publication, artifact
signing, infrastructure modification, release, or production
deployment that is subject to protected execution-finality control.
The Candidate Deployment Act may be represented by a descriptor
identifying the relevant code, artifact, target environment,
operation scope, policy epoch, freshness condition, and Finality
Sink.
In the Autonomous Code-Deployment Finality Gate embodiment, the
deployment operation remains non-effective until the required
protected authorization and release-capability conditions are
satisfied.
10.47. 47. Supply-Chain Authority Object
“Supply-Chain Authority Object” means an Authority Object defining
the protected authorization conditions applicable to a Candidate
Deployment Act or other governed software supply-chain operation.
Its validation may involve the permitted repository, code changes,
dependencies, build or deployment configuration, artifact identity,
test and scanner results, required approvals, deployment target,
policy state, and freshness conditions.
Where required by the Autonomous Code-Deployment Finality Gate
embodiment, the PED/CIED validates the Supply-Chain Authority Object,
generates the applicable Deployment LAVR or ZK-LAVR, and releases a
Scoped Release Capability.
The deployment Finality Sink verifies the capability before
effectuation.
10.48. 48. Screen-State Finality Object (SSFO)
“Screen-State Finality Object” (SSFO) means a protected object
created before a governed computer-use or graphical-user-interface
action becomes externally effective.
An SSFO may bind the contemporaneous screen-state hash, interface-
element identity, geometric target region, OCR or semantic label,
action type, application context, authorized user intent, risk class,
destination or Finality Sink, expiry, nonce, and chain-root
reference.
Das Expires 19 April 2027 [Page 99]
Internet-Draft Protected AI Execution Finality October 2026
The SSFO is distinct from an ordinary screenshot, accessibility-tree
record, or user-interface log.
The governed interface action proceeds only after the required SSFO
validation and corresponding scoped capability verification at the
applicable Finality Sink.
10.49. 49. Network Destination, Endpoint, and Route Scope
“Network Destination, Endpoint, and Route Scope” refers to machine-
verifiable restrictions governing where, how, or through which
authorized interface a Candidate Network or Sandbox Egress Act may
produce its permitted network consequence.
The applicable scope may identify a destination, API endpoint,
network route, interface, requesting workload, credential scope,
command class, permitted operation, policy epoch, freshness
condition, or Finality Sink.
Where the corresponding embodiment requires these predicates, the
PED/CIED validates the proposed network operation against the
applicable Authority Object.
A different destination, endpoint, or route is not authorized when it
exceeds the validated scope.
10.50. 50. Credential Broker
“Credential Broker” refers to an intermediary component or protected
service involved in mediating, obtaining, providing, or controlling
access to credentials used for a governed operation.
A Credential Broker may form part of a sandbox-egress, application,
network, or protected authorization path.
Where credential access or use constitutes a governed Candidate Act,
the applicable protected execution-finality conditions remain
mandatory.
The existence of a Credential Broker does not independently establish
Candidate Act-specific authorization, protected receipt commitment,
or Finality Sink verification.
A particular credential-storage, surrogate-token, or just-in-time
credential-substitution implementation is not mandatory under this
definition.
Das Expires 19 April 2027 [Page 100]
Internet-Draft Protected AI Execution Finality October 2026
10.51. 51. Surrogate Credentials
“Surrogate Credential” means a restricted credential reference,
substitute identifier, or non-authoritative token used by an
application or AI agent in place of an underlying protected
credential.
A Surrogate Credential may identify a credential-mediated operation
without directly exposing the underlying secret to the requesting
component.
Where implemented, use of the underlying credential remains subject
to the applicable authorization and protected execution-finality
requirements.
A Surrogate Credential is distinct from an Execution Handle, EASO,
and Scoped Non-Bearer Capability unless the embodiment expressly
establishes their functional relationship.
10.52. 52. Protected Credential Release
“Protected Credential Release” refers to a protected authorization
operation controlling the disclosure, application, signing use, or
availability of credential material for a governed Candidate Act.
The protected mechanism may validate the requesting identity,
authorized purpose, operation, destination, credential scope,
freshness, and applicable protected state.
Where a scoped execution capability is required, the corresponding
credential-mediated effect remains subject to the protected
capability and Finality Sink verification conditions.
Credential release does not necessarily require disclosure of the
underlying secret to the requesting agent.
10.53. 53. Privileged Connector
“Privileged Connector” means an intermediary component having
controlled access to a protected resource, service, credential,
application programming interface, or execution interface that is not
directly available to the requesting AI agent.
A Privileged Connector may perform operations on behalf of an agent
within a defined authorization scope.
Das Expires 19 April 2027 [Page 101]
Internet-Draft Protected AI Execution Finality October 2026
Where a connector operation constitutes a governed Candidate Act, its
effectuation remains subject to the applicable protected
authorization and Finality Sink verification.
The term does not inherently require a separate host process,
particular privilege-separation mechanism, or surrogate-credential
substitution.
10.54. 54. Service-Mesh and Proxy Finality Enforcement
“Service-Mesh and Proxy Finality Enforcement” refers to an execution-
finality arrangement in which a service mesh, sidecar proxy, ingress
or egress controller, API gateway, workload proxy, or equivalent
infrastructure component performs an applicable Finality Gate or
Finality Sink function.
A Candidate Act involving service-to-service communication, API
transmission, network egress, or downstream service invocation is
subjected to protected authorization.
Where required, the infrastructure component verifies a scoped
Execution-Enabling Capability bound to the relevant act, workload,
destination, route, policy state, and freshness conditions before
permitting effectuation.
10.55. 55. Protected Computation Admission
“Protected Computation Admission” refers to a protected authorization
mechanism controlling whether a proposed model invocation, inference
operation, training operation, computation task, or other governed
computational activity may begin or enter a specified execution
environment.
Admission may depend upon identity, approved ALF, permitted model or
workflow, execution scope, policy state, and applicable attestation
or freshness conditions.
Where the corresponding embodiment requires a protected admission
capability, computation is withheld until the capability verifies.
Authorization to begin computation does not independently authorize a
subsequent network transmission, output release, payment, deployment,
or other separately governed consequential operation.
Das Expires 19 April 2027 [Page 102]
Internet-Draft Protected AI Execution Finality October 2026
10.56. 56. Model Authorization and External Execution Authorization
“Model Authorization” refers to verification that a model,
algorithmic logic, configuration, or computational workflow satisfies
the applicable authority, integrity, provenance, or approved-ALF
conditions.
“External Execution Authorization” refers to verification that a
particular Candidate Act is permitted to produce its governed
consequential effect.
These are distinguishable authorization functions.
Successful Model Authorization does not independently confer
authority to transmit generated data, invoke external tools, release
credentials, commit transactions, or perform downstream operations
where separate execution-finality validation is required.
10.57. 57. Candidate Commerce Act
“Candidate Commerce Act” means a proposed commercial, marketplace,
auction, advertising, pricing, recommendation, negotiation, purchase,
payment, or inventory-related operation subject to protected
execution-finality control.
Such acts may include bids, purchases, offers, ranking changes, price
adjustments, payment instructions, ad placements, and inventory
allocations.
In the Market-Intent and Auction-Integrity Finality Gate embodiment,
the PED/CIED validates the applicable Market-Compliance Authority
Object, generates a Market-Integrity LAVR or ZK-LAVR, and releases a
Commerce Actuation Capability.
The applicable commerce Finality Sink verifies the capability before
the governed act becomes effective.
10.58. 58. Destination Resolution and Redirect Control
“Destination Resolution and Redirect Control” refers to verification
that the destination, endpoint, recipient, network route, or
downstream effectuation target of a Candidate Act remains within its
applicable authorized scope.
Where required, a changed endpoint, destination, route, or redirected
operation must satisfy the protected authorization conditions
applicable to the operation actually presented for effectuation.
Das Expires 19 April 2027 [Page 103]
Internet-Draft Protected AI Execution Finality October 2026
A previous authorization does not automatically permit an
unauthorized destination substitution.
Specific DNS-resolution, IP-address comparison, redirect-chain
inspection, or DNS-rebinding prevention mechanisms are additional
implementation requirements when expressly claimed.
10.59. 59. Confidential Virtual Machine (Confidential VM)
“Confidential Virtual Machine” means a virtualized execution
environment employing hardware-supported or equivalent protected-
computing mechanisms to protect specified workload code, data,
memory, or execution state against adversaries within its defined
threat model.
A Confidential VM may provide protected runtime isolation, measured
launch state, memory encryption, integrity protection, or attestation
according to its implementation.
A Confidential VM may host a Protected Enforcement Domain or a
governed AI workload.
Confidential computation does not, by itself, establish Candidate
Act-specific authorization, protected validation-evidence commitment,
scoped capability release, or Finality Sink verification.
10.60. 60. Hardware Attestation
“Hardware Attestation” refers to a machine-verifiable assertion or
evidence structure establishing specified hardware, firmware,
software, workload, configuration, or protected-execution
measurements under an applicable hardware-rooted trust mechanism.
Attestation may be used to validate a Protected Enforcement Domain,
confidential workload, hardware enforcement component, protected key
state, or execution context.
Attestation evidence may be incorporated into applicable Authority
Predicates or capability-binding conditions.
Successful attestation establishes only the properties covered by the
verified evidence and trust assumptions; it does not independently
authorize every Candidate Act executed within the attested
environment.
Das Expires 19 April 2027 [Page 104]
Internet-Draft Protected AI Execution Finality October 2026
10.61. 61. Hardware Trust Root and Virtual Trusted Platform Module
(vTPM)
“Hardware Trust Root” means a hardware-protected source of
cryptographic identity, key protection, measurement, attestation, or
integrity verification used to establish trust in an applicable
protected execution or enforcement mechanism.
A hardware trust root may comprise a TPM, secure element, HSM,
hardware security processor, or equivalent protected component.
“Virtual Trusted Platform Module” (vTPM) refers to a virtualized
interface providing TPM-related functions to a virtual machine,
subject to the security and key-protection properties of its
implementation.
Use of a hardware trust root or vTPM does not independently establish
Candidate Act-specific execution authority.
10.62. 62. Hardware Composite Algorithmic Logic Fingerprint (ALF)
“Hardware Composite ALF” refers to a proposed implementation of a
Composite Algorithmic Logic Fingerprint incorporating hardware-
related measurements or execution conditions alongside applicable
model, software, workflow, configuration, or policy measurements.
Such information may include hardware execution mode, accelerator
configuration, protected-domain attestation, software state, approved
model state, and applicable runtime configuration.
The resulting fingerprint may be evaluated against an approved ALF
condition.
Hardware measurement or ALF correspondence does not independently
replace required protected authorization, scoped capability release,
or Finality Sink verification.
10.63. 63. User-Controlled Root Key
“User-Controlled Root Key” means a cryptographic root key, root
secret, or equivalent protected keying authority whose permitted use,
derivation, release, or revocation is controlled by an identified
user or authorized user-controlled security mechanism.
In an implementation employing such a key, subordinate cryptographic
material may be derived, wrapped, or made available subject to the
applicable key-access and authorization conditions.
Das Expires 19 April 2027 [Page 105]
Internet-Draft Protected AI Execution Finality October 2026
User control does not necessarily require exposing the root-key
material to an application or AI agent.
A User-Controlled Root Key is distinct from an Authority Object and
does not independently authorize a Candidate Act to become externally
effective.
10.64. 64. Derived and Wrapped Keys
“Derived Key” means cryptographic key material produced from another
secret or protected keying input through an applicable key-derivation
mechanism.
“Wrapped Key” means cryptographic key material protected through
encryption or a key-wrapping mechanism for controlled storage,
transfer, or use.
In protected execution-finality embodiments, derived or wrapped keys
may enable an authorized decryption, signing, transmission, release,
or other governed operation.
Where required, the protected mechanism binds key availability or use
to the corresponding Candidate Act, protected authorization state,
and Finality Sink verification.
10.65. 65. Cryptographic Authorization Commitment
“Cryptographic Authorization Commitment” means a cryptographically
protected representation associating specified authorization
information with a Candidate Act, protected validation state, or
execution-enablement condition.
Such a commitment may bind a Candidate Act Descriptor, Authority
Object reference, validated predicates, protected-state transition,
policy epoch, nonce, receipt commitment, permitted execution scope,
or Finality Sink identity.
The commitment may comprise a cryptographic digest, MAC, signature,
Merkle commitment, sealed record, or equivalent authenticated
representation.
A Cryptographic Authorization Commitment does not independently
constitute an execution capability unless the applicable embodiment
expressly assigns and enforces that function.
Das Expires 19 April 2027 [Page 106]
Internet-Draft Protected AI Execution Finality October 2026
10.66. 66. Hardware Freshness
“Hardware Freshness” refers to a hardware-supported or hardware-
protected condition used to establish the current validity, sequence,
generation, or non-replayed status of execution-related authorization
state.
Hardware freshness may be represented through secure counters,
hardware-backed nonces, monotonic state, protected measurements,
trusted timing state, or equivalent protected values.
Where required by the embodiment, a scoped execution capability may
be bound to hardware freshness state.
A stale, replayed, rolled-back, or unverifiable required freshness
condition does not establish valid execution authority.
10.67. 67. Hardware Finality Latch
“Hardware Finality Latch” refers to a hardware-enforced
implementation of a Finality Latch that prevents a governed Candidate
Act from crossing its Execution-Finality Boundary unless the required
scoped execution capability or corresponding protected enablement
condition is verified.
The latch may control queue admission, DMA mapping, memory access,
network forwarding, storage commitment, accelerator egress, RF
activation, optical modulation, or another consequential interface.
A Hardware Finality Latch may be implemented within a processor,
accelerator, controller, NIC, SmartNIC, DPU, FPGA, ASIC, or
equivalent enforcement component.
Hardware presence alone does not establish that the relevant
effectuation path is non-bypassable.
10.68. 68. Candidate Fabric Transfer Act
“Candidate Fabric Transfer Act” means a proposed transfer, routing,
switching, replication, multicast, DMA, or delivery operation
involving AI computation state, tensors, activations, memory content,
model outputs, or other governed information between compute,
accelerator, memory, or fabric domains.
The Candidate Fabric Transfer Act may be represented by a descriptor
identifying the source, destination, transfer scope, relevant
protected state, policy conditions, and fabric Finality Sink.
Das Expires 19 April 2027 [Page 107]
Internet-Draft Protected AI Execution Finality October 2026
Where the applicable embodiment requires protected fabric finality,
the PED/CIED validates the Cross-Domain Fabric Authorization Object
and releases the required Fabric Transfer Capability.
The fabric Finality Sink verifies the capability before permitting
the governed transfer.
10.69. 69. Virtual-Machine Snapshot Rollback
“Virtual-Machine Snapshot Rollback” refers to restoration or
attempted restoration of a virtual machine, container, application,
model-runtime, or associated execution state to an earlier recorded
state.
In a protected execution-finality embodiment, rollback must not
restore authorization previously consumed, revoked, expired, denied,
or otherwise invalidated under mandatory protected-state conditions.
Rollback protection may employ sealed state, monotonic counters,
protected epochs, authenticated state continuity, or equivalent
mechanisms.
Where a required protected-state mismatch is detected, the affected
Candidate Act remains non-effective pending valid protected recovery
or renewed authorization.
10.70. 70. Migration, Recovery, and Failover
“Migration, Recovery, and Failover” refers to movement, restoration,
continuation, or transfer of a governed workload, protected execution
function, authorization state, or Finality Sink responsibility
between execution environments or components.
Such events may include workload migration, component replacement,
service restart, recovery from failure, or activation of a standby
enforcement mechanism.
Where protected execution-finality continuity is required, the
receiving or restored environment must satisfy the applicable
authority, policy, revocation, freshness, protected-state,
capability-consumption, and Finality Sink conditions before
permitting governed effectuation.
Migration or failover does not independently create or restore
execution authority.
Das Expires 19 April 2027 [Page 108]
Internet-Draft Protected AI Execution Finality October 2026
10.71. 71. Workload and Tenant Identity
“Workload Identity” means a machine-verifiable identity associated
with a computational workload, service, application, agent, process,
virtual machine, container, model execution, or corresponding
execution context.
“Tenant Identity” means an identity associated with a logical or
organizational tenant whose resources, data, policies, or execution
authority are governed within a shared or distributed computing
environment.
Workload and Tenant Identities may form part of a Candidate Act
Descriptor, Authority Object, Runtime Context, or protected
authorization predicate.
Successful identity verification does not independently confer
authority to effectuate a Candidate Act.
10.72. 72. Cloud Control Plane
“Cloud Control Plane” means a computing or orchestration layer
responsible for configuring, scheduling, managing, deploying, or
coordinating cloud workloads, infrastructure resources, permissions,
network paths, or associated services.
A Cloud Control Plane may prepare, request, transmit, or administer a
Candidate Act or applicable authorization information.
Where the operation is governed by protected execution-finality
requirements, the Cloud Control Plane cannot independently substitute
its administrative authority for the required protected validation
and Finality Sink verification.
Cloud administration permission does not automatically constitute
authority for a particular external effect.
10.73. 73. Watchdog Monitoring State
“Watchdog Monitoring State” refers to machine-verifiable information
generated or maintained by a watchdog, runtime monitor, protected
controller, security processor, or equivalent monitoring mechanism
concerning the condition of a governed computing or enforcement
component.
Such information may concern availability, integrity, fault
conditions, reset events, execution anomalies, or enforcement-path
status.
Das Expires 19 April 2027 [Page 109]
Internet-Draft Protected AI Execution Finality October 2026
Where required by an embodiment, monitoring information may inform
protected validation, denial, recovery, or quarantine decisions.
A watchdog observation does not independently constitute an execution
capability, and a watchdog failure does not create authority to
bypass protected finality enforcement.
10.74. 74. Quarantine
“Quarantine” means a restricted technical state or enforcement action
in which a Candidate Act, output, workload, artifact, resource, or
other governed operation is held, isolated, suppressed, or prevented
from producing further unauthorized effects.
Quarantine may occur before effectuation when protected validation
fails or authorization remains unresolved.
In an implementation supporting post-event containment, quarantine
may also restrict subsequent activity following detection of an
unauthorized or suspicious condition.
Quarantine after an effect has occurred does not retroactively
prevent that completed effect or independently satisfy a required
pre-effectuation Finality Sink check.
10.75. 75. Multiple Finality Sinks
“Multiple Finality Sinks” refers to an execution arrangement in which
a workflow contains two or more distinct governed effectuation
boundaries, each associated with a consequential operation or
operation phase.
Such boundaries may include network transmission, tool execution,
database commitment, payment settlement, model-output release, or
physical actuation.
Where the applicable embodiment requires separate sink authorization,
each Finality Sink verifies its own scoped execution capability or a
capability expressly bound to that sink and phase.
Authorization at one Finality Sink does not independently authorize
effectuation at another.
Das Expires 19 April 2027 [Page 110]
Internet-Draft Protected AI Execution Finality October 2026
10.76. 76. Distributed Revocation
“Distributed Revocation” refers to the propagation, synchronization,
validation, or enforcement of revocation-related authorization state
across multiple protected enforcement components, authority domains,
workloads, or Finality Sinks.
Such state may be represented through authenticated revocation
records, protected revocation epochs, signed policy updates, short-
lived authority windows, protected caches, or equivalent mechanisms.
Where current non-revocation is mandatory, each applicable
enforcement component verifies the revocation information required by
its authorization rules.
Unavailable, stale beyond the permitted freshness window, or invalid
required revocation state does not create execution authority.
10.77. 77. Out-of-Band Monitoring and Inline Enforcement
“Out-of-Band Monitoring” refers to observation, collection, analysis,
or communication of governance-related information through a
mechanism logically separate from the governed operation's principal
effectuation path.
“Inline Enforcement” refers to a mechanism positioned within, or in
effective mandatory control of, a governed effectuation path so that
the consequential operation depends upon satisfying the applicable
enforcement conditions.
Out-of-band information may inform protected authorization, policy
updates, revocation, quarantine, or recovery.
Observation or detection alone does not establish that an inline or
otherwise non-bypassable Finality Sink prevented an external effect.
The required prevention guarantee depends upon the actual enforcement
arrangement.
10.78. 78. Cross-Component Authorization Consistency
“Cross-Component Authorization Consistency” refers to the required
correspondence of Candidate Act identity, authorization scope,
protected policy state, execution epoch, revocation state, capability
bindings, and effectuation conditions among components participating
in a governed execution-finality sequence.
Das Expires 19 April 2027 [Page 111]
Internet-Draft Protected AI Execution Finality October 2026
Where the applicable embodiment requires such consistency, the
protected enforcement mechanism verifies that an operation is not
effectuated using incompatible or invalid required authorization
states.
Consistency may be maintained through authenticated commitments,
protected state references, epoch verification, sink-specific
capabilities, or equivalent protected mechanisms.
The term does not independently require global consensus,
instantaneous synchronization, or a single centralized authorization
authority.
Explanatory definitions of key technical words:
10.79. 1. Protected Enforcement Domain (PED)
“Protected Enforcement Domain” (PED) means a protected execution,
authority, governance, or enforcement boundary configured to perform
or control one or more protected execution-finality functions
associated with a Candidate Act, including applicable authorization-
predicate validation, protected-state handling, validation-evidence
generation or commitment, scoped execution-capability control,
Finality Gate support, and fail-closed withholding.
A PED may be implemented in hardware, firmware, software, a
hypervisor, microkernel, TEE, HSM, secure enclave, secure element,
protected controller, gateway, SmartNIC, DPU, FPGA, distributed
protected authority arrangement, or equivalent protected environment,
provided the required protected enforcement relationship is
preserved.
A PED may be physically separate from, integrated with, or colocated
with other system components. A Cryptographically Isolated
Enforcement Domain (CIED) is a stronger protected implementation with
additional cryptographic-isolation properties.
10.80. 2. Finality Sink (FS)
“Finality Sink” (FS) means a technical effectuation boundary at which
a governed Candidate Act would first become externally effective,
practically usable, transmitted, committed, rendered, stored,
decrypted, signed, forwarded, admitted, settled, actuated, energized,
or otherwise consequential.
Das Expires 19 April 2027 [Page 112]
Internet-Draft Protected AI Execution Finality October 2026
A Finality Sink may comprise a hardware, firmware, software,
protocol, network, storage, database, payment, rendering,
cryptographic, memory, accelerator, communication, or physical-
control interface, provided the interface controls the relevant
effectuation boundary.
Where required by the applicable embodiment, the Finality Sink
verifies a scoped execution capability or corresponding protected
enablement condition before permitting effectuation.
The Finality Sink may be integrated with or physically separate from
the PED or Finality Gate, provided the applicable protected
verification and non-bypassable effectuation requirements are
satisfied.
10.81. 3. Candidate Act (CA)
“Candidate Act” (CA) means a proposed, requested, generated,
computed, derived, prepared, staged, buffered, selected, planned,
delegated, scheduled, or otherwise pending operation that, if
permitted to proceed, would produce a governed consequential effect.
A Candidate Act may include an AI-generated output, tool invocation,
API request, network transmission, file or database operation, model
update, credential operation, computation-admission request, data or
memory transfer, financial transaction, deployment, rendering event,
communication, cryptographic operation, or physical actuation.
Where applicable, a governed omission, timeout, non-renewal, or
failure to maintain a required state may also constitute a Candidate
Act.
A Candidate Act does not independently become authorized or effective
merely because it has been computed, generated, approved,
authenticated, or prepared.
10.82. 4. Compute Plane (CP)
“Compute Plane” (CP) means one or more computational components,
environments, or execution resources configured to receive, process,
generate, transform, prepare, or stage data, instructions, model
outputs, execution requests, or Candidate Acts.
The Compute Plane may comprise an AI model, autonomous agent,
application, process, tool runtime, container, virtual machine, cloud
workload, CPU, GPU, NPU, TPU, FPGA, accelerator, model-serving
system, edge device, distributed compute cluster, or heterogeneous
computing infrastructure.
Das Expires 19 April 2027 [Page 113]
Internet-Draft Protected AI Execution Finality October 2026
The Compute Plane may be local, remote, cloud-hosted, edge-hosted,
virtualized, confidential, distributed, or physically integrated with
protected enforcement components.
For a governed Candidate Act, computation or operation preparation by
the Compute Plane does not independently confer the protected
authority required to cross the applicable Execution-Finality
Boundary. Physical integration does not eliminate the distinct
computation and authorization functions.
11. Detailed Execution-Finality Workflows
11.1. WF-01 — Universal Protected Execution-Finality Workflow for AI
and Autonomous Computing Systems
11.1.1. WF-01.1 — Technical Field and Purpose
The present workflow describes a computer-implemented execution-
finality architecture configured to prevent a Candidate Act
generated, selected, prepared, or initiated by an artificial-
intelligence system or other computational component from becoming
externally effective unless the applicable protected authorization
and execution-enablement conditions have been satisfied.
The workflow separates the ability to perform computation from the
authority to cause a consequential operation.
The architecture comprises a Compute Plane, a Candidate Act holding
mechanism, a Candidate Act Descriptor, a Protected Enforcement Domain
(PED), protected authorization state, protected validation evidence,
a scoped non-bearer execution capability, and a Finality Sink
controlling the applicable effectuation boundary.
The described sequence may be implemented within a single node,
device, chip, host, gateway, cloud workload, or protected controller,
or across multiple cooperating components, provided that the required
authorization and effectuation relationships are preserved.
11.1.2. WF-01.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises:
Component CP-101 — Compute Plane
A computational environment comprising one or more AI agents, models,
processors, applications, tools, virtual machines, containers,
accelerators, or associated execution resources configured to prepare
operations.
Das Expires 19 April 2027 [Page 114]
Internet-Draft Protected AI Execution Finality October 2026
The Compute Plane may generate a proposed operation but does not
independently control the protected capability required to effectuate
that operation.
Component HI-102 — Holding and Interception Mechanism
A component configured to intercept, receive, stage, buffer, or
otherwise hold a proposed operation before it crosses the governed
execution-finality boundary.
The mechanism may comprise a kernel broker, hypervisor-controlled
interface, sandbox broker, protected queue, API gateway, network-
egress proxy, file-operation broker, hardware output buffer, or
equivalent interception component.
Component DC-103 — Descriptor Construction Mechanism
A component configured to obtain and represent the Candidate Act and
its effectuation-relevant execution context using a deterministic
machine-readable descriptor.
The descriptor construction mechanism may be integrated with the
interception mechanism or PED.
Component PED-104 — Protected Enforcement Domain
A protected authorization and enforcement environment configured to
validate the applicable Candidate Act against required authority
predicates, perform protected-state operations, generate or commit
protected validation evidence, and control release or availability of
a scoped execution capability.
Component PS-105 — Protected State Store
A protected, authenticated, or otherwise enforcement-controlled state
mechanism holding applicable policy, freshness, nonce, quota,
revocation, usage, validation-commitment, and capability-consumption
information.
The state store may be integrated within PED-104 or maintained
through another protected arrangement satisfying the required
security properties.
Component EO-106 — Protected Validation Evidence Mechanism
Das Expires 19 April 2027 [Page 115]
Internet-Draft Protected AI Execution Finality October 2026
A protected mechanism for generating or committing a validation
receipt, authenticated state record, sealed receipt, LAVR, AVR,
cryptographic commitment, or equivalent protected evidence associated
with the validation result.
Component CR-107 — Capability Release Mechanism
A mechanism controlled by PED-104 that generates, derives, activates,
releases, or otherwise makes available the required scoped non-bearer
execution capability following the applicable protected finality
transaction.
Component FS-108 — Finality Sink
An effectuation interface configured to verify the required execution
capability against the operation presented for effectuation and to
refuse the operation unless the mandatory capability-verification
conditions are satisfied.
Component EF-109 — Effectuation Interface
The controlled interface through which a verified Candidate Act
produces its permitted consequence, including network transmission,
tool invocation, API execution, file commitment, signing, credential
use, storage modification, payment settlement, output release, memory
transfer, or physical actuation.
PED-104, CR-107, FS-108, and EF-109 may be colocated or distributed.
Functional distinction does not require physical separation unless
expressly specified.
11.1.3. WF-01.3 — System Initialization
Before processing governed operations, the system establishes the
applicable protected execution-finality configuration.
The initialization procedure comprises:
(a) identifying the operation classes subject to protected
effectuation control;
(b) identifying the corresponding Finality Sinks and effectuation
boundaries;
(c) establishing the applicable Authority Objects and authorization-
predicate definitions;
(d) initializing protected policy and revocation state;
Das Expires 19 April 2027 [Page 116]
Internet-Draft Protected AI Execution Finality October 2026
(e) establishing any required cryptographic capability-issuance or
authentication keys;
(f) establishing the trusted verification relationship between
PED-104 and FS-108;
(g) initializing required freshness, nonce, usage, and receipt-
commitment state; and
(h) configuring the governed execution path so that the Compute Plane
cannot directly bypass the corresponding enforcement interface.
In a cryptographic implementation, PED-104 may maintain a protected
private capability-signing key while FS-108 maintains the
corresponding authenticated verification key.
In a single-node implementation, the protected authority and sink may
instead employ a protected internal capability table, sealed state,
or hardware-controlled enablement condition.
The protected authority configuration is not writable by an untrusted
agent merely because that agent can execute within CP-101.
11.1.4. WF-01.4 — Establishment of the Governed Execution Path
The system configures each governed effectuation interface so that
the Candidate Act cannot produce its specified consequence without
passing through the applicable Finality Sink.
For an illustrative sandbox-network embodiment, this may be
implemented by placing the AI-agent runtime within an isolated
network namespace lacking an independent external transmission route
and directing permitted outbound operations through an enforcement-
controlled network interface.
The system may additionally restrict direct access to host sockets,
raw network interfaces, privileged device nodes, credential stores,
file-system mutation interfaces, and other effect-capable resources
that would bypass the governed path.
The actual interception mechanism is selected according to the
operating system, hypervisor, network infrastructure, hardware
interface, or execution substrate.
For a single-node gateway embodiment, the same protected node may
maintain the Candidate Act, validate its authority, commit evidence,
release the capability, verify it at a local sink, and control the
output interface.
Das Expires 19 April 2027 [Page 117]
Internet-Draft Protected AI Execution Finality October 2026
For a distributed embodiment, PED-104 and FS-108 communicate through
an authenticated channel or verify an authenticated capability
representation.
A non-bypassable guarantee applies to the effectuation paths actually
controlled by the implemented enforcement arrangement.
11.1.5. WF-01.5 — Generation of a Candidate Act
CP-101 generates or prepares a proposed operation.
Non-limiting operations include:
(a) an HTTP request;
(b) a tool invocation;
(c) an application programming interface call;
(d) a shell command;
(e) a file write;
(f) a credential-mediated service invocation;
(g) a model-runtime or policy mutation;
(h) a delegated agent operation;
(i) a data or tensor transfer;
(j) a transaction instruction; or
(k) another operation capable of producing a governed consequence.
The resulting proposed operation is designated Candidate Act CA-110.
Generation of CA-110 does not itself constitute authorization to
execute the operation.
11.1.6. WF-01.6 — Interception and Non-Effective Staging
HI-102 receives or intercepts CA-110 before the operation reaches EF-
109.
The interception mechanism assigns an operation identifier and places
CA-110 into a Non-Effective State.
Das Expires 19 April 2027 [Page 118]
Internet-Draft Protected AI Execution Finality October 2026
The operation may be maintained as a queued request, retained
command, buffered payload, pending tool invocation, protected
transaction descriptor, inactive hardware operation, or equivalent
staged representation.
The system prevents the effectuation interface from processing the
operation while the required protected validation conditions remain
unresolved.
A representative state record comprises:
operation_id;
candidate_act_reference;
requesting_context;
target_sink;
status = NON_EFFECTIVE;
created_at;
applicable_policy_reference.
The record may be maintained within protected state, a holding queue
subject to protected release control, or another enforcement-
controlled location.
The underlying request payload may remain outside the PED where an
authenticated descriptor or digest is sufficient for the required
validation.
11.1.7. WF-01.7 — Construction of the Candidate Act Descriptor
DC-103 obtains the effectuation-relevant attributes of CA-110 and
constructs a Candidate Act Descriptor.
The descriptor may contain:
act_id;
act_class;
requesting_agent_or_workload;
source_execution_context;
Das Expires 19 April 2027 [Page 119]
Internet-Draft Protected AI Execution Finality October 2026
operation_parameters;
payload_digest;
destination_or_resource;
requested_effect;
authority_object_reference;
policy_epoch;
finality_sink_id;
finality_boundary_id;
nonce;
expiry;
permitted_scope_reference.
Only the fields required by the applicable embodiment need be
included.
Where a cryptographic descriptor is used, the descriptor is
canonicalized under a defined deterministic encoding procedure.
A non-limiting descriptor-binding expression is:
D = CanonicalEncode_v(Fields(CA, X, F))
where:
D denotes the canonical Candidate Act Descriptor;
CA denotes the proposed Candidate Act;
X denotes the effectuation-relevant runtime execution context;
F denotes the applicable Finality Sink identity;
Fields denotes extraction or assembly of the required descriptor
fields;
CanonicalEncode_v denotes a deterministic encoding procedure of
specified version v.
Das Expires 19 April 2027 [Page 120]
Internet-Draft Protected AI Execution Finality October 2026
The version identifier permits the receiving verifier to interpret
the same descriptor fields using the intended representation rules.
An illustrative cryptographic descriptor digest is:
hD = H("DAS-CA-v1" || D)
where:
hD denotes the descriptor digest;
H denotes an approved cryptographic hash function;
"DAS-CA-v1" denotes an illustrative domain-separation label;
|| denotes concatenation of encoded values.
The particular hash algorithm and serialization method are
implementation-dependent.
The described mathematical representation is an illustrative
implementation of the disclosed deterministic descriptor-binding
function, not a mandatory cryptographic algorithm for every
embodiment.
11.1.8. WF-01.8 — Acquisition of Applicable Authority
PED-104 obtains or resolves one or more applicable Authority Objects.
An Authority Object may identify the permitted operation class,
purpose, destination, resource, authority issuer, requesting
identity, execution scope, policy epoch, freshness requirements,
revocation conditions, and other mandatory authorization predicates.
The applicable Authority Object may be:
(a) supplied to the PED through an authenticated interface;
(b) retrieved from an authenticated authority store;
(c) referenced by an Execution Handle;
(d) associated with an Execution Authorization Scope Object; or
(e) obtained from another protected source permitted by the
embodiment.
Das Expires 19 April 2027 [Page 121]
Internet-Draft Protected AI Execution Finality October 2026
PED-104 verifies the required authenticity, scope, validity, and
issuer conditions before treating the authority information as valid.
A requesting agent cannot establish authorization merely by supplying
a self-declared Authority Object.
11.1.9. WF-01.9 — Protected Authorization-Predicate Validation
PED-104 evaluates the mandatory authorization predicates associated
with CA-110.
Such predicates may concern:
(a) requesting agent or workload identity;
(b) permitted operation class;
(c) authorized purpose;
(d) requested destination;
(e) permitted execution scope;
(f) applicable policy epoch;
(g) revocation state;
(h) nonce or freshness;
(i) protected quota or usage allowance;
(j) required human approval;
(k) Algorithmic Logic Fingerprint;
(l) Algorithmic Intent Fingerprint;
(m) Runtime Behavioral Descriptor;
(n) required attestation; or
(o) other conditions required by the applicable Authority Object.
For a conjunctive predicate set, validation may be expressed as:
V = P1(D,A,S,X) AND P2(D,A,S,X) AND ... AND Pn(D,A,S,X)
where:
Das Expires 19 April 2027 [Page 122]
Internet-Draft Protected AI Execution Finality October 2026
V denotes the protected validation result;
P1 through Pn denote the mandatory authorization predicates;
n denotes the number of required predicates;
D denotes the Candidate Act Descriptor;
A denotes the applicable Authority Object or authenticated authority
context;
S denotes the relevant protected authorization state;
X denotes the required Runtime Context.
V is true only when all mandatory predicates satisfy their respective
validation rules.
An embodiment employing a quorum, approved alternatives, or threshold
conditions evaluates those conditions according to its corresponding
protected policy rather than requiring literal conjunction of every
possible predicate.
If any mandatory condition fails or cannot be established, the system
withholds the required execution authority.
11.1.10. WF-01.10 — Protected Authorization-State Operation
When the applicable authorization predicates succeed, PED-104
performs the protected-state operation required for the Candidate
Act.
The protected-state operation may comprise:
(a) consumption of a nonce;
(b) reservation or decrement of quota;
(c) protected usage-counter advancement;
(d) recording of an authorized operation identifier;
(e) verification or advancement of a state-generation value;
(f) registration of a receipt commitment;
(g) reservation of a capability instance; or
Das Expires 19 April 2027 [Page 123]
Internet-Draft Protected AI Execution Finality October 2026
(h) another protected authorization-state transition.
Where an atomic protected-state transition is required, PED-104
prevents two concurrent requests from independently consuming the
same restricted authorization state.
For example, when a capability is limited to one authorized use, the
protected state store may perform an atomic compare-and-update
operation against the relevant operation and authorization-state
version.
If the required protected state cannot be updated consistently,
capability issuance does not succeed.
11.1.11. WF-01.11 — Generation and Commitment of Protected Validation
Evidence
Following successful validation and in coordination with the required
protected-state operation, EO-106 generates or commits Protected
Validation Evidence.
An illustrative record may contain:
receipt_id;
candidate_act_digest;
validated_predicate_reference;
authority_reference;
protected_state_transition_digest;
policy_epoch;
freshness_reference;
finality_sink_id;
finality_boundary_id;
decision = ALLOW;
protected_domain_authentication.
The evidence may comprise a signed receipt, protected register
commitment, sealed record, LAVR, AVR, hash-chain entry, Merkle
commitment, or another protected representation.
Das Expires 19 April 2027 [Page 124]
Internet-Draft Protected AI Execution Finality October 2026
The evidence is committed before, or atomically with, making the
corresponding scoped non-bearer capability available.
Where the implementation permits later external publication or ledger
anchoring, the protected commitment is not delayed merely because
publication has not yet occurred.
An ordinary post-event audit record does not replace the mandatory
pre-effectuation evidence commitment.
11.1.12. WF-01.12 — Protected Finality Transaction
PED-104 establishes the required dependency between successful
validation, protected-state handling, validation-evidence commitment,
and capability availability.
A non-limiting protected transaction is represented as:
(S_next, R, Ready) = CommitFinality(D, A, S_current, F)
where:
S_current denotes the protected authorization state before the
transaction;
S_next denotes the protected authorization state after successful
commitment;
R denotes the committed protected validation evidence;
Ready denotes a protected indication that all required pre-release
conditions have completed;
D denotes the validated Candidate Act Descriptor;
A denotes the applicable authority context;
F denotes the designated Finality Sink.
The transaction succeeds only when its required state and evidence
operations are consistent and committed under the selected protected
implementation.
The capability-release mechanism does not treat an incomplete or
failed commitment as successful authorization.
Das Expires 19 April 2027 [Page 125]
Internet-Draft Protected AI Execution Finality October 2026
A protected transaction may be implemented through transactional
storage, sealed-state machinery, a protected register protocol, an
HSM-controlled procedure, or an equivalent protected arrangement.
Where a transaction spans components that do not support a single
atomic storage transaction, the capability remains unavailable until
the required committed dependencies have been verified.
11.1.13. WF-01.13 — Generation of Scoped Non-Bearer Capability
Upon successful completion of the required protected finality
transaction, CR-107 creates or makes available a scoped non-bearer
execution capability.
In an illustrative signature-based implementation:
C = Sign_skPED(Encode(hD, hR, F, Scope, Epoch, N, Expiry, CID))
where:
C denotes the authenticated execution capability;
Sign denotes digital-signature generation;
skPED denotes a private signing key protected under control of PED-
104;
Encode denotes the specified deterministic encoding procedure;
hD denotes the authorized Candidate Act Descriptor digest;
hR denotes the protected validation-evidence commitment digest;
F denotes the authorized Finality Sink;
Scope denotes the permitted effectuation scope;
Epoch denotes the required policy or execution epoch;
N denotes the capability freshness or nonce value;
Expiry denotes the capability validity limit;
CID denotes a unique capability identifier.
These values are illustrative. The particular claim or embodiment
determines which bindings are mandatory.
Das Expires 19 April 2027 [Page 126]
Internet-Draft Protected AI Execution Finality October 2026
The corresponding verification key is provisioned to the authorized
Finality Sink.
The capability is non-bearer under the described arrangement because
successful presentation remains dependent upon verification against
the required operation, sink, authorization state, freshness, scope,
and consumption conditions.
A signature alone does not establish non-bearer behavior unless the
necessary contextual restrictions are actually enforced.
11.1.14. WF-01.14 — Transfer or Availability of the Capability
The capability may be made available to FS-108 through:
(a) an authenticated inter-component interface;
(b) an authenticated protected queue;
(c) a sealed shared-memory mechanism;
(d) an internal protected capability table;
(e) an authenticated response to an effectuation request;
(f) a hardware-controlled capability register; or
(g) another protected means supported by the embodiment.
The system may transmit a compact capability representation rather
than the entire validation evidence or original Candidate Act
payload.
The Compute Plane may receive a capability reference where
appropriate, but such receipt does not permit the agent to alter the
capability or bypass required sink-side verification.
11.1.15. WF-01.15 — Reconstruction or Verification at the Finality Sink
Before permitting CA-110 to produce its governed effect, FS-108
obtains the operation actually presented at EF-109.
The Finality Sink determines the relevant actual operation attributes
and constructs or verifies the corresponding effectuation descriptor.
Let:
D_actual = CanonicalEncode_v(Fields(CA_actual, X_actual, F))
Das Expires 19 April 2027 [Page 127]
Internet-Draft Protected AI Execution Finality October 2026
where:
CA_actual denotes the operation actually presented for effectuation;
X_actual denotes the relevant execution context at the sink;
F denotes the Finality Sink performing verification;
D_actual denotes the resulting effectuation descriptor.
Where exact descriptor correspondence is required:
H("DAS-CA-v1" || D_actual) = hD
Where the authorization expressly permits bounded variations, the
sink instead verifies the required exact bindings together with the
applicable bounded-scope predicates.
The Finality Sink must not regard an unauthorized change of target,
payload, operation class, destination, scope, or other required
descriptor field as valid merely because the requesting agent
previously obtained an approval.
11.1.16. WF-01.16 — Capability Verification at the Finality Sink
FS-108 verifies the scoped capability using the required
authentication and state-verification mechanisms.
In the illustrative signature-based implementation, verification
comprises:
(a) verifying the capability signature using an authenticated PED
verification key;
(b) verifying the authorized Finality Sink identity;
(c) verifying the Candidate Act Descriptor or authorized operation
scope;
(d) checking the applicable policy epoch;
(e) validating required expiry and freshness conditions;
(f) checking the required revocation state;
(g) verifying the protected validation-evidence reference;
(h) verifying required protected usage or consumption state; and
Das Expires 19 April 2027 [Page 128]
Internet-Draft Protected AI Execution Finality October 2026
(i) confirming that the actual requested operation remains within the
permitted effectuation scope.
The authorization result may be expressed as:
Permit = Auth(C) AND Match(C,D_actual) AND ScopeValid(C,F) AND
StateValid(C,S_next,R)
where:
Permit denotes the Finality Sink's decision for the governed
operation;
Auth denotes verification of the required capability authenticity;
Match denotes verification of exact descriptor correspondence or
applicable bounded-scope matching;
ScopeValid denotes verification of the permitted Finality Sink and
execution scope;
StateValid denotes verification of required protected state, receipt,
freshness, revocation, and usage conditions.
All mandatory conditions must be true for Permit to be true.
A Finality Sink need not reproduce every computationally intensive
upstream predicate when the capability and required protected
commitments provide sufficient authenticated evidence of those
earlier results.
11.1.17. WF-01.17 — Protected Capability Consumption
Where the capability is single-use or usage-bounded, the Finality
Sink performs or coordinates the protected consumption operation
required by the applicable authorization.
An illustrative protected capability-state record comprises:
capability_id;
authorized_act_digest;
authorized_sink;
remaining_uses;
state_version;
Das Expires 19 April 2027 [Page 129]
Internet-Draft Protected AI Execution Finality October 2026
status.
Before final effectuation, the Finality Sink verifies that the
capability remains within its permitted usage state.
The implementation may use a protected atomic compare-and-update
operation, authenticated capability-consumption service, protected
hardware counter, or equivalent state mechanism.
For a single-use capability, a concurrent second attempt cannot
independently succeed against the same available usage state.
If the usage state is already consumed, revoked, exhausted, or
otherwise invalid, the corresponding operation is refused.
For operations whose external effect cannot be atomically committed
together with local capability consumption, the system separately
maintains the applicable pending, reserved, effective, failed, or
indeterminate completion state.
11.1.18. WF-01.18 — Controlled External Effectuation
If all mandatory Finality Sink verification conditions succeed,
FS-108 enables only the operation and effectuation scope authorized
by the verified capability.
Examples include:
(a) forwarding the authorized network request;
(b) invoking the approved tool;
(c) permitting a specified file operation;
(d) releasing a credential for its authorized use;
(e) committing an approved database operation;
(f) applying an authorized model or policy modification;
(g) admitting a permitted fabric transfer; or
(h) enabling an authorized physical-control operation.
The effectuation interface does not receive unrestricted authority to
execute additional operations outside the verified scope.
Das Expires 19 April 2027 [Page 130]
Internet-Draft Protected AI Execution Finality October 2026
After the permitted effectuation event, the system records or updates
the applicable protected completion and capability-consumption state.
The exact meaning of successful external completion depends upon the
controlled interface. Transmission acceptance by a local gateway,
for example, does not automatically prove downstream processing or
remote transaction completion.
11.1.19. WF-01.19 — Illustrative Network-Egress Implementation
In one concrete implementation, an AI agent executes within an
isolated sandbox and generates an HTTPS POST request to an authorized
application programming interface.
The sandbox lacks direct external network connectivity and can submit
external requests only through an enforcement-controlled host egress
broker.
The broker retains the proposed request in a pending state and
constructs a canonical descriptor identifying the requesting sandbox,
request method, destination, resource path, request-body digest,
applicable authority scope, policy epoch, and designated network
Finality Sink.
PED-104 authenticates the applicable Sandbox Egress Authority Object
and validates the required operation, purpose, destination, policy,
runtime-context, and freshness conditions.
After successful validation, the PED performs the required protected-
state transition, commits the corresponding validation evidence, and
releases a Sandbox Egress Capability bound to the validated request
and network-egress Finality Sink.
The host egress interface verifies the capability against the actual
request presented for transmission and the required current
authorization state.
If verification succeeds, the host egress interface transmits the
authorized request.
If the request method, destination, required request content, policy
state, nonce, capability state, or other mandatory bound parameter
differs from the authorized conditions, the interface refuses
transmission unless renewed protected validation succeeds.
The source sandbox cannot independently open an alternative external
connection, and the protected egress authority cannot be replaced by
an agent-controlled software approval.
Das Expires 19 April 2027 [Page 131]
Internet-Draft Protected AI Execution Finality October 2026
This example illustrates one implementation. Other governed
effectuation interfaces may employ the same protected causal sequence
with operation-specific descriptors and capability-verification
mechanisms.
11.1.20. WF-01.20 — Failure, Timeout, and Denial Handling
The protected execution-finality workflow operates fail-closed.
A Candidate Act is not permitted to become effective when:
(a) descriptor construction fails;
(b) a required Authority Object is missing or invalid;
(c) a mandatory authorization predicate fails;
(d) protected state is unavailable or inconsistent;
(e) a required protected-state update fails;
(f) validation evidence cannot be committed;
(g) the required capability cannot be released;
(h) capability authentication fails;
(i) the actual operation does not match the authorized scope;
(j) required nonce, expiry, revocation, or policy conditions fail;
(k) required usage state is exhausted or already consumed; or
(l) Finality Sink verification cannot be established.
Depending upon the applicable embodiment, the operation may be
denied, retained in a pending state, quarantined, escalated for
review, or directed to an independently authorized recovery
procedure.
Where an operation has already produced an external effect,
subsequent denial cannot retroactively prevent that effect.
An interrupted or indeterminate operation is not automatically
reissued merely because a previous attempt timed out.
Das Expires 19 April 2027 [Page 132]
Internet-Draft Protected AI Execution Finality October 2026
11.1.21. WF-01.21 — Concurrency, Crash Recovery, and Duplicate-Effect
Handling
Where multiple Candidate Acts compete for shared protected
authorization state, the PED performs the required state checks and
updates with synchronization appropriate to the specified guarantees.
Protected transactions may use atomic compare-and-swap operations,
transaction isolation, monotonic counters, authenticated state
machines, protected locks, or equivalent mechanisms.
If processing fails before protected evidence commitment, no
corresponding valid capability is released.
If processing fails after evidence commitment but before capability
delivery, the protected system determines the committed authorization
state before deciding whether to return, retire, or regenerate an
associated capability.
If processing fails after the Finality Sink begins external
effectuation, the system distinguishes an operation known to be
incomplete from an operation whose completion status is unknown.
Where the external interface supports transaction identifiers,
idempotency keys, or completion queries, those mechanisms may support
reconciliation.
Where the external interface cannot establish whether an effect
occurred, automatic replay is withheld unless the applicable
protected recovery procedure establishes the required duplicate-
effect prevention condition.
This procedure does not assert unconditional exactly-once completion
across arbitrary external systems.
11.1.22. WF-01.22 — Alternative Structural Implementations
The described workflow may be implemented through different protected
enforcement substrates.
Single-node implementation: A protected controller, gateway, chip, or
AI-serving node performs descriptor validation, protected-state
handling, validation-evidence commitment, capability availability,
and local Finality Sink verification.
Separated implementation: A protected authority component performs
validation and capability issuance, while a separate effectuation
component verifies the capability before acting.
Das Expires 19 April 2027 [Page 133]
Internet-Draft Protected AI Execution Finality October 2026
Hardware-rooted implementation: A TEE, HSM, secure enclave, protected
processor, SmartNIC, DPU, FPGA, ASIC, or corresponding hardware-
controlled interface enforces the required protected state and
capability-dependent effectuation conditions.
Software-isolated implementation: A protected software or hypervisor-
controlled arrangement implements the corresponding logical sequence
within the security limitations of that enforcement substrate.
Distributed implementation: Multiple protected components participate
in authority, state, evidence, or sink verification, while the
required protected authorization relationships are preserved through
authenticated communication and state-consistency controls.
These implementations need not provide identical resistance to
privileged compromise, rollback, physical attack, or distributed
failure.
An embodiment expressly requiring hardware-rooted, cryptographically
isolated, rollback-resistant, or threshold-distributed guarantees
includes the additional mechanisms necessary to establish those
properties.
11.1.23. WF-01.23 — Technical Result
The workflow establishes a protected dependency between:
(a) generation of a Candidate Act;
(b) interception and Non-Effective State;
(c) machine-verifiable descriptor binding;
(d) protected authority-predicate validation;
(e) required protected-state handling;
(f) protected validation-evidence commitment;
(g) scoped non-bearer execution-capability availability;
(h) Finality Sink verification; and
(i) controlled external effectuation.
Das Expires 19 April 2027 [Page 134]
Internet-Draft Protected AI Execution Finality October 2026
The resulting technical arrangement prevents the governed
effectuation interface from treating agent computation, ordinary
approval, request possession, or an upstream allow decision as
sufficient execution authority.
The architecture is defined by the required protected causal
relationship rather than by the brand, operating system, processor
architecture, cryptographic algorithm, cloud platform, or physical
placement of its components.
Computation is not authority to act.
11.2. WF-02 — Protected AI-Agent Sandbox Isolation, Mandatory
Interception, and Host Egress Enforcement
11.2.1. WF-02.1 — Technical Purpose
This embodiment provides a protected execution-finality system for
governing operations initiated by an artificial-intelligence agent,
agentic workflow, autonomous tool, or associated computational
process executing within a sandboxed environment.
The system prevents a governed operation from becoming effective at a
host-system, network, file-system, application, credential, or other
consequential interface unless the applicable Protected Enforcement
Domain (PED) has validated the operation, established required
protected validation evidence, and released a scoped Sandbox Egress
Capability that is subsequently verified by the applicable Finality
Sink.
The sandbox may execute instructions, prepare requests, manipulate
temporary data, generate commands, and perform other computation.
Such activity does not independently confer authority to cross the
governed execution-finality boundary.
The embodiment is not limited to one operating system, container
runtime, hypervisor, processor architecture, network protocol, or
security-substrate implementation.
11.2.2. WF-02.2 — Participating Components
In one non-limiting implementation, the system comprises:
SE-201 — Sandboxed Execution Environment: An isolated agent runtime
comprising a container, virtual machine, restricted process, tool
runtime, browser automation runtime, notebook, serverless function,
or equivalent environment.
Das Expires 19 April 2027 [Page 135]
Internet-Draft Protected AI Execution Finality October 2026
IM-202 — Interception and Mediation Component: A protected or
enforcement-controlled mechanism receiving or intercepting governed
operations before those operations produce host or external effects.
HQ-203 — Non-Effective Holding Queue: A controlled staging facility
maintaining intercepted operations or immutable representations
thereof pending protected authorization.
DC-204 — Descriptor Construction Component: A component responsible
for constructing or validating a machine-verifiable Candidate Sandbox
Egress Act Descriptor.
PED-205 — Protected Enforcement Domain: A protected authority
environment responsible for the applicable authorization predicates,
protected-state handling, validation-evidence commitment, and scoped
capability-release control.
AS-206 — Protected Authorization-State Store: A protected mechanism
storing applicable policy versions, authority references, nonce
state, revocation state, usage conditions, validation commitments,
and other required authorization state.
EV-207 — Egress Validation-Evidence Component: A mechanism generating
or committing an Egress LAVR, ZK-LAVR, or other protected validation
evidence.
CR-208 — Sandbox Egress Capability Mechanism: A component generating,
deriving, registering, or releasing the scoped non-bearer capability
required by the applicable egress operation.
FS-209 — Host Finality Sink: An enforcement component that
independently verifies the required capability before allowing the
operation to produce its governed consequence.
EF-210 — Effectuation Interface: The controlled host, network, file-
system, tool-execution, credential, application, or other interface
through which an authorized operation becomes effective.
A component may perform more than one described function. The PED,
Finality Gate, and Finality Sink are distinguishable functional roles
and need not comprise physically separate devices.
11.2.3. WF-02.3 — Establishment of the Sandbox Trust Boundary
Before governed operations are processed, SE-201 is configured to
restrict direct access to the effectuation interfaces assigned to FS-
209.
Das Expires 19 April 2027 [Page 136]
Internet-Draft Protected AI Execution Finality October 2026
A non-limiting Linux implementation may employ:
(a) user and mount namespaces;
(b) a separate network namespace;
(c) restricted filesystem mounts;
(d) removal of unnecessary operating-system capabilities;
(e) seccomp-based syscall restrictions or user-notification
mediation;
(f) a kernel security module, eBPF-based enforcement where suitable,
or an operating-system policy broker;
(g) restricted host-device access;
(h) an authenticated host broker interface; and
(i) a separately protected authority service.
The sandbox is not provisioned with unrestricted host execution
privileges, protected capability-signing keys, or unmediated access
to governed host resources.
The exact mechanisms depend upon the operating system and threat
model.
For a virtual-machine implementation, equivalent restrictions may be
applied through a hypervisor-controlled device interface, virtual
network switch, protected virtual-device queue, or isolated host-
service broker.
For a cloud implementation, equivalent controls may be implemented
through a workload sandbox, network policy enforcement point,
protected gateway, or service-mesh infrastructure, subject to the
required bypass-prevention guarantees.
11.2.4. WF-02.4 — Identification of Governed Effectuation Paths
Before enabling the sandbox, the system identifies the interfaces
through which the agent can cause a governed consequential effect.
A representative interface registry contains:
The registry associates each governed operation class with the
mechanism that prevents unverified effectuation.
Das Expires 19 April 2027 [Page 137]
Internet-Draft Protected AI Execution Finality October 2026
The system is configured so that an agent cannot bypass the
registered enforcement path by selecting an alternative command,
process, device, communication channel, or execution interface
capable of producing the same governed effect.
The implementation must verify its actual effectuation-path coverage.
Merely maintaining a registry does not make an otherwise accessible
interface non-bypassable.
11.2.5. WF-02.5 — Mandatory Mediation and Path-Coverage Condition
Let:
E denote the set of governed effectuation interfaces;
P(e) denote the set of execution paths accessible to the sandbox that
can reach a particular interface e;
F(p) denote the required Finality Sink or protected finality-
verification mechanism governing path p.
The mandatory path-coverage condition is:
For every e in E, and for every sandbox-accessible p in P(e), the
governed effect may occur only after the applicable F(p) has
successfully verified the required execution authority.
This condition is evaluated within the defined trust model of the
particular implementation.
For example, routing HTTP traffic through an egress proxy is
insufficient if the sandbox retains an unrestricted raw-network
interface through which the same transmission may occur.
Likewise, wrapping shell commands is insufficient if the sandbox can
invoke an unrestricted alternative host-execution interface.
In one implementation, alternative effectuation paths are removed.
In another implementation, all permitted effectuation paths are
mediated by the corresponding protected Finality Sink.
11.2.6. WF-02.6 — Agent Operation Generation
An artificial-intelligence agent executes within SE-201 and generates
a proposed operation.
The operation may comprise:
Das Expires 19 April 2027 [Page 138]
Internet-Draft Protected AI Execution Finality October 2026
(a) a shell command;
(b) a host process-launch request;
(c) an application programming interface request;
(d) a network transmission;
(e) a persistent file modification;
(f) a package installation;
(g) a browser action;
(h) a credential request; or
(i) another governed host or external operation.
The generated operation is classified as Candidate Sandbox Egress Act
CA-211.
Generation, formatting, or submission of CA-211 does not authorize it
to cross the applicable effectuation boundary.
11.2.7. WF-02.7 — Interception Before Effectuation
IM-202 intercepts CA-211 before the governed effect occurs.
The interception mechanism may be implemented using one or more of:
(a) a container-runtime hook;
(b) a hypervisor trap;
(c) an operating-system policy broker;
(d) a kernel broker;
(e) a seccomp filter or supported user-notification mechanism;
(f) an eBPF-based enforcement component;
(g) a file-system policy module;
(h) a shell execution wrapper combined with mandatory host process
mediation;
(i) a browser automation controller;
Das Expires 19 April 2027 [Page 139]
Internet-Draft Protected AI Execution Finality October 2026
(j) a network-egress proxy; or
(k) an API gateway.
A syscall filter or kernel event hook may identify or block an
operation without understanding its full application-level contents.
Where authorization requires an HTTP method, application path,
message body, or other higher-layer field, those fields are obtained
through an appropriate trusted application-level broker or controlled
protocol-processing component.
For encrypted traffic, such inspection requires permitted decryption,
trusted endpoint cooperation, or another technically suitable
mechanism. A kernel-level packet hook alone is not assumed to reveal
encrypted application content.
11.2.8. WF-02.8 — Non-Effective Staging and Immutable Request
Representation
Following interception, IM-202 places CA-211 into HQ-203.
The operation is assigned an operation identifier and remains in a
Non-Effective State.
An illustrative operation record comprises:
operation_id
agent_identity
sandbox_identity
operation_class
request_reference
target_interface
policy_epoch
state_version
status = PENDING
created_at
Das Expires 19 April 2027 [Page 140]
Internet-Draft Protected AI Execution Finality October 2026
For operations containing mutable buffers, request bodies, command
arguments, or file content, the mediation component may copy the
effectuation-relevant material into a controlled staging buffer or
create a verified immutable representation.
The actual operation later presented for effectuation is checked
against the protected authorization commitment.
This prevents a requesting process from validating one operation and
substituting materially different parameters between validation and
execution.
The implementation may retain large payloads outside PED-205,
provided the relevant payload identity and integrity are bound to the
authorization record and verified at effectuation.
11.2.9. WF-02.9 — Candidate Sandbox Egress Act Descriptor
DC-204 constructs or validates a Candidate Sandbox Egress Act
Descriptor.
The descriptor may comprise:
agent identity;
sandbox identity;
host identity;
operation class;
executable identity or command digest;
command parameters;
target file path or resource;
network destination;
API endpoint;
credential scope;
browser action;
package identity;
input provenance;
Das Expires 19 April 2027 [Page 141]
Internet-Draft Protected AI Execution Finality October 2026
tool identity;
risk class;
policy epoch;
nonce;
expiry; and
Finality Sink identity.
Where exact operation binding is required, the descriptor includes or
securely references the effectuation-relevant parameters necessary to
distinguish authorized from unauthorized operations.
The descriptor may be canonicalized using a deterministic encoding
procedure.
For an illustrative implementation:
D = Canonicalize(ID, OP, TARGET, PARAM, CONTEXT, EPOCH, SINK)
where:
D means the canonical Candidate Sandbox Egress Act Descriptor;
ID means the requesting agent, sandbox, or workload identity;
OP means the proposed operation class;
TARGET means the intended destination or resource;
PARAM means the operation parameters required for authorization;
CONTEXT means the applicable runtime context;
EPOCH means the required policy or authorization-state version;
SINK means the designated Finality Sink identity.
Only the fields mandated by the particular Authority Object and
embodiment must participate in the corresponding binding.
11.2.10. WF-02.10 — Retrieval of Sandbox Egress Authority Object
PED-205 obtains an applicable Sandbox Egress Authority Object from an
authenticated authority source or protected state reference.
Das Expires 19 April 2027 [Page 142]
Internet-Draft Protected AI Execution Finality October 2026
The Authority Object identifies the permissions and restrictions
applicable to CA-211.
A non-limiting Authority Object may specify:
(a) permitted sandbox or workload identities;
(b) permitted command classes;
(c) authorized destinations;
(d) permitted file or resource scopes;
(e) allowed tool and API classes;
(f) applicable credential scopes;
(g) permitted execution purpose;
(h) required approval conditions;
(i) applicable runtime or provenance restrictions;
(j) quota and usage conditions;
(k) policy epoch and revocation conditions; and
(l) capability scope and validity restrictions.
PED-205 verifies the Authority Object according to the required
authentication and protected-state rules.
The requesting agent cannot create execution authority merely by
supplying an unauthorized policy statement or a self-signed approval
artifact.
11.2.11. WF-02.11 — Protected Authorization-Predicate Validation
PED-205 evaluates the Candidate Sandbox Egress Act against its
applicable Authority Object and protected authorization state.
The predicates may include:
Purpose validation: Whether the proposed operation remains within the
authorized sandbox purpose or applicable AIF envelope.
Das Expires 19 April 2027 [Page 143]
Internet-Draft Protected AI Execution Finality October 2026
Logic validation: Whether the operation corresponds to an approved
ALF, container image, workflow, tool graph, command policy, or
equivalent logic condition.
Behavioral validation: Whether an applicable RBD or provenance record
satisfies the required runtime-behavior conditions.
Destination validation: Whether the requested target, resource,
endpoint, or route remains within the permitted scope.
Credential-scope validation: Whether any requested credential-
mediated authority is permitted for the proposed operation.
Policy validation: Whether the current required policy epoch and
revocation conditions are satisfied.
Freshness validation: Whether applicable nonce, expiry, sequence, or
capability-use conditions are valid.
Human authorization: Whether an authenticated, act-bound human
approval is present when required.
For a conjunctive predicate set:
V = P1 AND P2 AND ... AND Pn
where:
V denotes the overall protected validation result;
P1 through Pn denote the mandatory predicates selected for the
particular Candidate Act;
n denotes the number of mandatory predicates.
V is true only if all required predicates succeed.
Where alternative predicates or an approved quorum are permitted,
their combination is evaluated according to the corresponding
protected policy.
ALF, AIF, and RBD evaluation are mandatory only when required under
the specified enforcement profile or embodiment.
11.2.12. WF-02.12 — Protected Grant-State and Freshness Handling
Upon successful predicate validation, PED-205 performs the protected-
state operations required for CA-211.
Das Expires 19 April 2027 [Page 144]
Internet-Draft Protected AI Execution Finality October 2026
Such operations may include:
(a) verifying the current policy epoch;
(b) checking revocation state;
(c) reserving or consuming an authorization nonce;
(d) decrementing an applicable operation quota;
(e) registering an operation-specific authorization grant;
(f) recording a capability-use limit;
(g) updating a protected receipt-chain state; or
(h) performing another required protected authorization transition.
Where an authorization permits only one consequential effect, the
relevant protected-state transition is coordinated to prevent
concurrent operations from independently consuming the same
authorization.
Where state consistency cannot be established, the system does not
treat the transaction as successfully authorized.
11.2.13. WF-02.13 — Egress Validation-Evidence Commitment
EV-207 generates or commits the Protected Validation Evidence
required for CA-211.
The evidence may comprise an Egress LAVR, ZK-LAVR, sealed validation
record, authenticated state commitment, or another supported
protected representation.
An illustrative evidence record identifies:
operation identifier;
Candidate Act Descriptor digest;
applicable Authority Object reference;
validated predicate-set reference;
protected-state transition;
decision result;
Das Expires 19 April 2027 [Page 145]
Internet-Draft Protected AI Execution Finality October 2026
policy epoch;
nonce or freshness state;
designated Finality Sink; and
protected authentication information.
Where the corresponding claim requires pre-effectuation evidence
commitment, the required evidence is committed before, or atomically
with, capability availability.
A conventional log generated only after host execution does not
substitute for that protected dependency.
The evidence may remain inside the PED or a protected state store and
need not be immediately exported to an external ledger.
11.2.14. WF-02.14 — Sandbox Egress Capability Issuance
Upon completion of the required protected finality transaction,
CR-208 releases or makes available a scoped, non-bearer Sandbox
Egress Capability.
The capability may comprise:
(a) an authenticated capability object;
(b) a protected execution handle;
(c) a sealed capability reference;
(d) a signed operation permit;
(e) a MAC-authenticated authorization artifact;
(f) a protected capability-table entry; or
(g) a hardware-controlled enablement condition.
Where required by the embodiment, the capability is bound to:
Candidate Act Descriptor;
operation class;
requester or sandbox identity;
Das Expires 19 April 2027 [Page 146]
Internet-Draft Protected AI Execution Finality October 2026
authorized destination;
permitted scope;
validation-evidence commitment;
policy epoch;
protected usage state;
nonce or expiry; and
Finality Sink identity.
A capability is not regarded as non-bearer merely because it has a
signature. The applicable Finality Sink must enforce the required
scope, context, state, and other non-bearer verification conditions.
11.2.15. WF-02.15 — Independent Host Finality Sink Verification
FS-209 receives the staged Candidate Act or a broker-controlled
representation of the operation and obtains the applicable execution
capability.
Before effectuation, FS-209 verifies:
(a) capability authenticity;
(b) correspondence to CA-211 or its authorized operation class;
(c) the requesting sandbox or execution-context binding;
(d) the operation parameters required by the authorization;
(e) the permitted destination or resource;
(f) Finality Sink identity;
(g) applicable policy and revocation state;
(h) nonce, expiry, and protected usage restrictions; and
(i) required validation-evidence commitment.
A verification condition may be represented as:
PERMIT = AUTH(C) AND MATCH(C, D_actual) AND SCOPE(C, F) AND STATE(C,
S_current)
Das Expires 19 April 2027 [Page 147]
Internet-Draft Protected AI Execution Finality October 2026
where:
C means the Sandbox Egress Capability;
D_actual means the actual effectuation-relevant descriptor presented
at the host interface;
F means the applicable Finality Sink;
S_current means the protected authorization state required at
verification time;
AUTH verifies required capability authenticity;
MATCH verifies exact correspondence or applicable bounded-scope
matching;
SCOPE verifies the permitted operation and Finality Sink;
STATE verifies required policy, revocation, freshness, receipt, and
consumption conditions.
The host operation is permitted only when PERMIT is true.
11.2.16. WF-02.16 — Host Shell and Executable-Specific Enforcement
In one implementation, host-executable operations are mediated by a
protected process-launch broker.
The sandbox submits a structured command request comprising an
executable identifier, argument vector, permitted environment,
working directory, requested resources, and target host-execution
context.
The broker resolves the executable against the permitted executable
identity or approved command class.
Where exact executable binding is required, authorization may cover
an authenticated executable digest, file identity, version, or other
measured execution artifact.
The requested arguments, environment variables, executable path,
interpreter use, and target resources are validated according to the
applicable Authority Object.
The host process-launch interface verifies the corresponding Sandbox
Egress Capability before invoking the controlled executable.
Das Expires 19 April 2027 [Page 148]
Internet-Draft Protected AI Execution Finality October 2026
A shell wrapper may prepare or submit the command but does not alone
constitute mandatory enforcement when an alternative host-execution
path remains accessible.
Where shell interpretation is authorized, the effectuation-relevant
command representation is captured and checked according to its
actual execution semantics, rather than assuming that a displayed
command string always identifies the executable operations that will
result.
11.2.17. WF-02.17 — Persistent File and Host-State Mutation Enforcement
In one implementation, the sandbox submits a proposed persistent-file
operation to an enforcement-controlled file broker.
The operation descriptor identifies the requested file operation,
authorized resource scope, relevant content digest where required,
and intended effectuation boundary.
A proposed write may be staged in temporary storage that cannot
modify the protected host target directly.
The broker validates the operation and obtains the corresponding
capability.
Before the persistent effect, the Finality Sink verifies the
capability against the actual destination and content or operation
parameters required by the authorization.
Where path substitution or filesystem races are relevant, the broker
may use controlled directory handles, resolved file identities,
protected filesystem operations, or equivalent mechanisms to prevent
a path from changing to an unauthorized target between checking and
use.
For a staged replacement, the broker may use a controlled commit
operation to move validated content into the authorized persistent
target.
If the requested target, content digest, authorization state, or
other mandatory binding fails, the file operation is refused.
The implementation also mediates alternative persistent-state
mutation paths that would otherwise bypass the controlled broker.
Das Expires 19 April 2027 [Page 149]
Internet-Draft Protected AI Execution Finality October 2026
11.2.18. WF-02.18 — Network and API Egress Enforcement
In a network-egress embodiment, the sandbox lacks direct access to
unrestricted external network transmission.
A controlled network broker or egress proxy receives the proposed
transmission.
The descriptor identifies the requesting workload, destination,
permitted network or API operation, applicable route, policy state,
and any required request parameters.
PED-205 validates the proposed operation and establishes the
corresponding protected evidence and Sandbox Egress Capability.
Before forwarding, the egress Finality Sink verifies the capability
against the actual request.
Where destination or application-level fields are mandatory, the
Finality Sink verifies those fields using a technically appropriate
representation of the request.
A destination change, redirect, connection reuse, or changed routing
target is not accepted when it violates a required authorization
binding.
Detailed hostname, address-resolution, redirect-chain and endpoint-
consistency alternatives are described further in Workflow WF-03.
11.2.19. WF-02.19 — Credential and Connector Boundary
Where the Candidate Sandbox Egress Act requires credential-mediated
authority, the sandbox may submit a protected credential-use request
rather than obtaining unrestricted access to the underlying
credential.
The credential broker or connector interface verifies the applicable
Sandbox Egress Capability before performing the credential-mediated
consequential operation.
Where the embodiment requires a separate credential-release or
credential-effectuation Finality Sink, that interface verifies the
operation-specific authority before applying the protected
credential.
The requesting agent's knowledge of a credential reference, connector
name, service endpoint, or earlier approval does not independently
authorize the credential-mediated effect.
Das Expires 19 April 2027 [Page 150]
Internet-Draft Protected AI Execution Finality October 2026
Detailed grant-state consumption, surrogate-reference substitution,
credential protection, and privileged-connector implementations are
described in WF-04 and WF-05.
11.2.20. WF-02.20 — Continuous Sandbox Egress and Micro-Receipts
For a continuing sandbox session, the protected system may maintain a
sequence of authorized egress operations rather than granting
unrestricted authority for the entire session.
Each governed command, API request, network transmission, or file
operation may require a corresponding validation event and micro-LAVR
or protected receipt-chain update.
Let:
R0 denote the initial protected receipt-chain state;
Di denote the descriptor for operation i;
Vi denote the protected validation result for operation i;
Ri denote the protected receipt-chain state after operation i;
H denote a cryptographic hash function;
|| denote concatenation of deterministically encoded values.
An illustrative update is:
Ri = H(R(i−1) || Di || Vi || Si)
where Si denotes the required protected-state commitment associated
with operation i.
This expression represents a possible hash-linked receipt-chain
implementation, not a mandatory format.
When an applicable runtime-behavior or authority predicate fails,
PED-205 withholds the next required Sandbox Egress Capability.
Previously authorized effects are not retroactively undone, but
subsequent unverified operations remain non-effective.
11.2.21. WF-02.21 — Runtime Drift, Revocation, and Policy Updates
During an ongoing agent session, the applicable authorization
conditions may change.
Das Expires 19 April 2027 [Page 151]
Internet-Draft Protected AI Execution Finality October 2026
A policy update, revocation event, exhausted quota, detected runtime-
behavior deviation, invalidated tool class, or other required state
transition may invalidate further capability use.
PED-205 updates or consults the corresponding protected authorization
state.
Where required, the Finality Sink checks the current policy epoch,
revocation state, and capability-consumption information before
effectuation.
A capability issued under a superseded authorization condition does
not authorize a later operation where the changed condition is
mandatory.
An agent-proposed policy expansion does not independently change the
protected policy. Such an expansion may constitute a separate
Candidate Self-Mutation Act governed through WF-09.
11.2.22. WF-02.22 — Failure and Containment Handling
The workflow operates fail-closed for mandatory protected
authorization conditions.
Failure conditions include:
(a) unavailable interception service;
(b) inability to hold the operation before effectuation;
(c) invalid Candidate Act Descriptor;
(d) missing or invalid Sandbox Egress Authority Object;
(e) failed purpose or scope validation;
(f) invalid provenance or runtime condition where required;
(g) stale policy or revocation state;
(h) failed protected-state transition;
(i) failed validation-evidence commitment;
(j) invalid or missing Sandbox Egress Capability;
(k) Finality Sink identity mismatch;
Das Expires 19 April 2027 [Page 152]
Internet-Draft Protected AI Execution Finality October 2026
(l) operation substitution; or
(m) failed required capability verification.
The resulting response may comprise denial, continued staging,
quarantine, simulation without the governed external effect, or an
authorized escalation procedure.
A human-review decision, denial log, or quarantine state does not
independently release execution authority.
If an operation has already produced a consequential effect, later
quarantine prevents only subsequent governed effects; it does not
erase or retroactively prevent the earlier effect.
11.2.23. WF-02.23 — Crash, Retry, and Capability-Reuse Handling
Where a broker, sandbox, PED, or Finality Sink crashes before
authorization completes, the pending operation remains subject to the
required protected validation conditions.
Where the protected evidence or capability state was already
committed, the system consults the corresponding operation
identifier, protected usage state, and completion status before
deciding whether another execution attempt is permitted.
A previously consumed single-use capability cannot authorize another
effectuation.
An operation having indeterminate completion status is not
automatically replayed where such replay could cause an unauthorized
duplicate external effect.
Where supported by the external interface, idempotency keys,
transaction identifiers, completion queries, or protected
reconciliation procedures may be used.
The particular embodiment determines the actual recovery guarantee.
11.2.24. WF-02.24 — Alternative Enforcement Implementations
The disclosed functional sequence may be implemented through the
following non-limiting alternatives.
Container-based implementation: A restricted container executes the
agent, while an enforcement-controlled host broker intercepts
governed operations and cooperates with a protected authority and
host Finality Sink.
Das Expires 19 April 2027 [Page 153]
Internet-Draft Protected AI Execution Finality October 2026
Hypervisor-based implementation: A virtual machine executes the
agent, while a hypervisor-controlled device or service interface
mediates governed effectuation requests.
Kernel-mediated implementation: Operating-system policy mechanisms,
syscall mediation, filesystem controls, and protected execution
brokers enforce the applicable host boundaries.
Proxy-based implementation: Governed network and service requests are
directed through an enforcement-controlled proxy or gateway that
verifies required capability bindings before forwarding.
Hardware-assisted implementation: A SmartNIC, DPU, protected host
controller, secure processor, or hardware-controlled interface
prevents governed output until the required bounded capability
condition is verified.
Single-node implementation: A protected host or controller performs
interception, validation, protected-state handling, evidence
commitment, capability generation, and local Finality Sink
verification within one protected node.
Distributed implementation: A remotely located PED releases an
authenticated capability that is verified by a separate host Finality
Sink.
The implementation substrate determines the strength of protection
against privileged software, hypervisor compromise, hardware
tampering, rollback, and other threats.
A software-only mechanism does not automatically possess hardware-
rooted security guarantees.
11.2.25. WF-02.25 — Technical Verification and Test Conditions
A person having ordinary skill in the art may verify the described
workflow through controlled tests including:
Test A — Unauthorized destination: Submit an operation targeting a
destination outside the permitted scope. The operation must not pass
the governed Finality Sink.
Test B — Changed operation: Validate one command or file operation,
then present materially different required parameters. The Finality
Sink must reject the mismatch.
Das Expires 19 April 2027 [Page 154]
Internet-Draft Protected AI Execution Finality October 2026
Test C — Missing capability: Present a governed operation without the
required Sandbox Egress Capability. The effectuation interface must
refuse it.
Test D — Replay: Re-present a consumed single-use capability. The
interface must reject use inconsistent with its protected consumption
state.
Test E — Policy revocation: Change a required policy or revocation
state. Subsequent affected operations must fail unless reauthorized
under valid current state.
Test F — Alternative path: Attempt the same governed host effect
through another accessible sandbox interface. The operation must
remain mediated or be blocked.
Test G — Concurrent requests: Submit concurrent operations using a
single-use authorization state. The protected mechanism must prevent
unauthorized duplicate consumption.
Test H — Broker failure: Make the required interception or
verification component unavailable. The corresponding governed
effect must not become authorized through an unprotected fallback.
Test I — Continuous session drift: Cause a required runtime
authorization condition to become invalid during an ongoing session.
Further affected egress capabilities must be withheld.
These tests demonstrate the security properties of the implemented
enforcement boundaries under the stated threat model.
11.2.26. WF-02.26 — Technical Effect
The embodiment establishes a protected execution-finality
relationship between the sandboxed Compute Plane and effect-capable
host or external interfaces.
The agent may compute, plan, prepare commands, request tools, or
construct network operations, but cannot independently cause a
governed effect through a controlled Finality Sink without satisfying
the required authorization conditions.
The protected relationship includes:
(a) mandatory interception;
(b) Non-Effective State staging;
Das Expires 19 April 2027 [Page 155]
Internet-Draft Protected AI Execution Finality October 2026
(c) Candidate Sandbox Egress Act Descriptor formation;
(d) protected authority-predicate validation;
(e) required protected-state handling;
(f) Egress LAVR, ZK-LAVR, or equivalent protected evidence
commitment;
(g) scoped Sandbox Egress Capability availability;
(h) independent Finality Sink verification; and
(i) controlled effectuation or fail-closed withholding.
The resulting architecture governs the transition from agent
computation to host or external effectuation, rather than relying
exclusively upon sandbox membership, ordinary permissions, an
upstream approval decision, or post-event logging.
Computation is not authority to act.
11.3. WF-03 — Network Authorization, Canonical Requests, Destination
Resolution, Redirect Consistency, and Executable-Specific Egress
Control
11.3.1. WF-03.1 — Technical Purpose
This embodiment describes a computer-implemented network execution-
finality arrangement configured to control network transmissions,
application programming interface requests, connector-mediated
operations, service-to-service calls, and other externally effective
network operations prepared or initiated by an artificial-
intelligence agent or associated computational workload.
The embodiment addresses circumstances in which an operation may be
authorized for a particular executable, requesting workload,
destination, network route, protocol, request method, resource path,
or execution context, but the operation actually presented for
effectuation differs from the authorized operation because of name
resolution, destination substitution, redirection, connection reuse,
process substitution, request mutation, or a change in protected
authorization state.
Das Expires 19 April 2027 [Page 156]
Internet-Draft Protected AI Execution Finality October 2026
The architecture maintains the proposed operation in a Non-Effective
State until the applicable Protected Enforcement Domain (PED)
establishes the required authorization conditions, commits protected
validation evidence, and releases or makes available a scoped, non-
bearer execution capability.
The corresponding network Finality Sink independently verifies the
capability against the actual operation and the applicable current
authorization state before allowing transmission, forwarding,
connection establishment, or another defined network effect.
A capability authorizing one network operation does not independently
authorize a different operation or effectuation boundary.
11.3.2. WF-03.2 — Participating Technical Components
In a non-limiting embodiment, the system comprises:
NE-301 — Agent Network Execution Environment
An agent, tool, browser, application, container, virtual machine, or
other workload capable of preparing network operations.
NI-302 — Network Interception Component
A component configured to intercept a proposed network operation
before the governed network effectuation boundary.
HQ-303 — Network Holding Queue
An enforcement-controlled staging mechanism maintaining a proposed
network operation in a Non-Effective State.
DC-304 — Network Descriptor Construction Component
A mechanism for constructing and canonicalizing an effectuation-
relevant network operation descriptor.
DR-305 — Destination Resolution Component
A DNS resolver, protected resolver interface, destination-
classification service, service-discovery mechanism, or equivalent
component configured to identify a destination or its permitted
resolution results.
PED-306 — Protected Enforcement Domain
Das Expires 19 April 2027 [Page 157]
Internet-Draft Protected AI Execution Finality October 2026
A protected component configured to authenticate the applicable
authority, validate the operation, maintain or verify protected
authorization state, commit required evidence, and control scoped
capability availability.
AS-307 — Protected Authorization-State Store
A protected mechanism maintaining applicable policy epochs,
revocation state, operation identifiers, usage state, freshness
conditions, and authorization commitments.
EV-308 — Protected Egress Evidence Component
A mechanism configured to generate or commit an Egress LAVR, ZK-LAVR,
authenticated validation record, or equivalent protected evidence.
CR-309 — Network Capability Release Component
A protected component configured to generate, register, or make
available the required scoped Network Egress Capability or Sandbox
Egress Capability.
NF-310 — Network Finality Sink
An enforcement-controlled network interface, socket broker, proxy,
API gateway, service-mesh component, network-forwarding controller,
SmartNIC, DPU, or equivalent interface performing required
verification before the governed network effect.
CE-311 — Connection Effectuation Component
A controlled mechanism configured to establish or use an authorized
network connection or perform another permitted transmission.
RM-312 — Redirect and Route Consistency Monitor
An optional component configured to identify destination changes,
redirections, connection reuse, or route changes that affect
mandatory authorization bindings.
EI-313 — Executable Identity Verification Component
An optional component configured to bind the requesting executable,
tool, process, workload, or approved execution logic to the
applicable network authorization.
Das Expires 19 April 2027 [Page 158]
Internet-Draft Protected AI Execution Finality October 2026
The described functions may be implemented within one protected node
or distributed across multiple cooperating components. The Finality
Sink may be integrated with the network broker or located at a
separate controlled network or receiving-side boundary.
11.3.3. WF-03.3 — Establishment of the Controlled Network Path
Before the agent begins governed execution, the system configures the
network environment so that the agent cannot independently perform
the governed network effect through an unrestricted alternative
interface.
In one illustrative Linux implementation, the agent executes in a
separate network namespace having no direct unrestricted route to
external networks.
The namespace may communicate with an enforcement-controlled host
broker through a designated local IPC interface, virtual network
interface, proxy endpoint, or equivalent mechanism.
The host or infrastructure enforces restrictions against alternative
direct transmission through raw sockets, unrestricted host
networking, unauthorized tunnels, or other accessible paths that
could circumvent the designated Finality Sink.
In another embodiment, the interception mechanism comprises a
virtual-machine network device, hypervisor-controlled virtual switch,
cloud network gateway, service-mesh egress controller, SmartNIC, or
DPU.
The protected network architecture identifies the interfaces that can
cause the relevant external effect and ensures that those interfaces
are governed.
A conventional proxy configuration that the agent can disable or
bypass does not, by itself, establish non-bypassable enforcement.
11.3.4. WF-03.4 — Candidate Network Act Generation
The agent prepares a proposed network operation, which may comprise:
(a) an HTTP or HTTPS request;
(b) a REST, GraphQL, RPC, or other API invocation;
(c) a service-to-service request;
(d) a WebSocket or other persistent-session operation;
Das Expires 19 April 2027 [Page 159]
Internet-Draft Protected AI Execution Finality October 2026
(e) a credential-mediated connector request;
(f) a file upload or download;
(g) a package or dependency retrieval;
(h) an outbound notification;
(i) a database or message-bus request;
(j) a model-service invocation; or
(k) another operation that would cause a governed network
consequence.
The proposed operation is classified as Candidate Network Act CNA-
314, which may constitute a Candidate Sandbox Egress Act.
CNA-314 remains non-effective pending the applicable protected
authorization and Finality Sink verification.
11.3.5. WF-03.5 — Capture of the Actual Request Representation
NI-302 intercepts CNA-314 before network effectuation.
For an application-level request, the interception component may
capture or construct a structured request containing:
operation_id;
requesting_workload;
executable_identity;
protocol;
request_method;
scheme;
authority_host;
destination_port;
resource_path;
query_parameters;
Das Expires 19 April 2027 [Page 160]
Internet-Draft Protected AI Execution Finality October 2026
request_headers;
request_body_digest;
credential_scope;
policy_epoch;
finality_sink_id.
Fields not required by the applicable authorization are optional.
The interceptor obtains effectuation-relevant parameters from a
controlled representation of the request rather than relying solely
on an untrusted descriptive string supplied by the agent.
For example, an agent's statement that a request is directed to an
approved service does not establish the destination actually used by
the network effectuation component.
Where the operation payload can change before transmission, the
system uses a controlled staging buffer, immutable reference,
authenticated content digest, or equivalent binding.
11.3.6. WF-03.6 — Canonical Network Operation Descriptor
DC-304 constructs a canonical representation of the operation.
One illustrative representation is:
Dnet = Canon_v(ID, EXE, PROTO, HOST, PORT, METHOD, PATH, BODY, ROUTE,
EPOCH, SINK)
where:
Dnet denotes the canonical network operation descriptor;
Canon_v denotes deterministic canonical encoding under specified
version v;
ID denotes the authenticated requesting identity or workload context;
EXE denotes the executable, tool, process, or approved execution-
logic identity where required;
PROTO denotes the network or application protocol;
HOST denotes the intended destination hostname or service identity;
Das Expires 19 April 2027 [Page 161]
Internet-Draft Protected AI Execution Finality October 2026
PORT denotes the applicable destination port;
METHOD denotes the requested application operation or HTTP method
where relevant;
PATH denotes the applicable resource path and authorized query scope;
BODY denotes the required request-body identity, digest, or permitted
content class;
ROUTE denotes the authorized network or service route where
applicable;
EPOCH denotes the applicable protected policy or authorization-state
version;
SINK denotes the designated Finality Sink identity.
The representation distinguishes absent fields from empty fields and
includes unambiguous lengths, types, and encoding rules.
Where exact request equality is required, the same canonicalization
version and field interpretation are used by the protected
authorization component and the Finality Sink.
An illustrative descriptor commitment is:
hnet = H("DAS-NET-v1" || Encode(Dnet))
where:
hnet denotes the network descriptor digest;
H denotes a cryptographic hash function;
Encode denotes the specified deterministic byte encoding;
|| denotes concatenation;
"DAS-NET-v1" denotes an illustrative domain-separation label.
The particular encoding and cryptographic algorithms are
implementation choices and are not mandatory for every embodiment.
11.3.7. WF-03.7 — Request-Normalization Rules
The system establishes normalization rules appropriate to the
governed protocol.
Das Expires 19 April 2027 [Page 162]
Internet-Draft Protected AI Execution Finality October 2026
For HTTP operations, such rules may address:
(a) scheme representation;
(b) hostname case normalization where appropriate;
(c) Internationalized Domain Name encoding;
(d) destination-port normalization;
(e) percent-encoded path interpretation;
(f) duplicate or ambiguous request-header interpretation;
(g) conflicting message-length indicators;
(h) HTTP authority and Host-header consistency;
(i) query-parameter handling;
(j) request-body identity; and
(k) protocol version and upgrade semantics.
Normalization must preserve distinctions that affect authorization or
actual request meaning.
The system must not treat two requests as equivalent merely because a
textual normalization procedure makes their displayed forms appear
similar.
Where the proxy and downstream server can interpret an ambiguous
request differently, the implementation either rejects the ambiguity
or uses a shared, authoritative parse of the operation that is
actually transmitted.
The authorization representation is therefore bound to the protocol
semantics enforced by the chosen Finality Sink.
11.3.8. WF-03.8 — Destination Classification and Resolution
DR-305 obtains the destination information required by the applicable
Authority Object.
For a hostname-based request, the resolution component may obtain one
or more IP addresses through an approved resolver or service-
discovery mechanism.
Das Expires 19 April 2027 [Page 163]
Internet-Draft Protected AI Execution Finality October 2026
The resolution result may include:
hostname;
canonical service identity;
resolved_addresses;
address_family;
destination_port;
resolution_generation;
resolution_validity;
service_discovery_context.
In one implementation, the network authorization service classifies
resolved addresses into policy-defined categories, including
permitted public addresses, private-network addresses, loopback
addresses, link-local addresses, cloud-service endpoints, or other
restricted destination classes.
Where destination restrictions are specified, the corresponding
network permission depends upon the actual resolved or selected
destination satisfying those restrictions.
A permitted public hostname does not automatically authorize
transmission to a prohibited private-network endpoint.
A hostname classification may be combined with IP-address
classification, destination service identity, permitted route,
authenticated server identity, or another verified destination
attribute.
11.3.9. WF-03.9 — Resolution-Dependent Authorization
In an embodiment requiring destination-resolution consistency,
protected authorization is associated with the relevant resolution
state.
Let:
R(h,t) denote the set of network addresses returned by the approved
destination-resolution mechanism for hostname h at validation time t.
Let:
Das Expires 19 April 2027 [Page 164]
Internet-Draft Protected AI Execution Finality October 2026
Allowed(ip,A) denote whether address ip satisfies the destination
restrictions specified by Authority Object A.
Let:
ip_selected denote the destination network address actually selected
for the connection.
The corresponding destination predicate may be expressed as:
Pdest = Allowed(ip_selected,A) AND
ResolutionValid(ip_selected,R(h,t),A)
where:
Pdest denotes the destination-authorization predicate;
Allowed checks applicable address-class, address-range, service, or
destination restrictions;
ResolutionValid checks that the selected destination satisfies the
authorized resolution or service-discovery conditions.
The policy may authorize an exact address, an approved address set, a
defined service identity, a permitted destination class, or another
bounded destination scope.
The system does not require an exact IP-address match when a broader
authorized service class is expressly permitted and adequately
enforced.
If the selected destination fails a mandatory destination predicate,
the network operation remains non-effective.
11.3.10. WF-03.10 — DNS Rebinding and Address-Substitution Handling
In a more specific implementation, the system protects against
destination changes occurring between authorization and connection
establishment.
For example, a hostname may initially resolve to an authorized public
address and subsequently resolve to a prohibited private or loopback
address.
If the system authorizes the original hostname but transmits to a
newly selected prohibited address without rechecking the applicable
destination predicate, the effective destination may differ from the
authorized destination.
Das Expires 19 April 2027 [Page 165]
Internet-Draft Protected AI Execution Finality October 2026
To prevent such substitution, the enforcement-controlled connection
component verifies the destination actually selected for connection
against the required protected authorization binding.
The verification may occur:
(a) immediately before the connection attempt;
(b) through a protected resolver-to-connection handoff;
(c) through an authenticated destination-selection record;
(d) through a policy-controlled connection broker; or
(e) through another arrangement that ensures correspondence between
the authorized and actual destination.
A DNS response alone does not establish the identity of the connected
peer.
Where the policy additionally requires server authentication, the
system validates the corresponding authenticated endpoint identity.
Where address translation, tunneling, service discovery, or routing
intermediaries affect destination identity, the binding is defined at
the network boundary the implementation actually controls.
An implementation does not assert visibility of a final remote
destination that is hidden behind an untrusted intermediary.
11.3.11. WF-03.11 — Executable-Specific Network Authorization
EI-313 may bind the network operation to an approved executable,
tool, agent runtime, workload, or other execution component.
The applicable executable identity may comprise:
(a) an authenticated executable digest;
(b) a measured executable image;
(c) an approved package or software identity;
(d) an approved runtime or container image;
(e) a process identity linked to a protected launch event;
(f) a signed executable identity;
Das Expires 19 April 2027 [Page 166]
Internet-Draft Protected AI Execution Finality October 2026
(g) an ALF representing approved logic or tool configuration; or
(h) a combination of required execution measurements.
An illustrative executable authorization predicate is:
Pexe = ExecApproved(EXE,A) AND ContextMatches(ID,EXE,X)
where:
Pexe denotes executable-specific authorization;
EXE denotes the verified executable or tool identity;
A denotes the applicable Authority Object;
ID denotes the authenticated requesting identity;
X denotes the relevant runtime execution context;
ExecApproved verifies that the executable or logic identity is
authorized for the requested operation;
ContextMatches verifies that the operation originates from the
execution context associated with the authorized identity.
A caller-provided process name or executable path alone is not
sufficient when the applicable embodiment requires authenticated
executable identity.
In one implementation, the host broker obtains process identity and
executable measurements through a trusted operating-system interface
or protected launch record.
The system may associate authorization with an opened executable
object, measured process image, or authenticated workload identity to
reduce executable substitution between checking and use.
Interpreters, dynamically loaded code, scripts, plug-ins, or modified
runtime state may require additional measurement or scope conditions
where those elements affect the applicable authorization.
11.3.12. WF-03.12 — Combined Executable and Destination Scope
A network permission may require correspondence among:
(a) the requesting workload;
Das Expires 19 April 2027 [Page 167]
Internet-Draft Protected AI Execution Finality October 2026
(b) the executable or approved logic class;
(c) the destination;
(d) the permitted operation;
(e) the protected authorization state; and
(f) the designated Finality Sink.
For example, one approved agent tool may be permitted to retrieve
public documentation, while a separate credential-bearing connector
may be permitted to communicate only with a particular authenticated
service.
The permission granted to the first tool does not independently
authorize the second tool's credential-bearing operation.
Where required, the Protected Enforcement Domain verifies the
executable-to-destination relationship before releasing the
corresponding capability.
A capability bound to one executable identity cannot be reused by
another executable when that identity forms part of the mandatory
authorization binding.
11.3.13. WF-03.13 — Protected Authority Validation
PED-306 receives or reconstructs the canonical Candidate Network Act
Descriptor and obtains the applicable Network Egress Authority Object
or Sandbox Egress Authority Object.
The PED evaluates required predicates that may include:
(a) requester identity;
(b) executable or logic identity;
(c) authorized purpose;
(d) destination hostname or service identity;
(e) actual permitted address class;
(f) port and transport protocol;
(g) HTTP method or applicable API operation class;
Das Expires 19 April 2027 [Page 168]
Internet-Draft Protected AI Execution Finality October 2026
(h) resource path and query scope;
(i) authorized network route;
(j) permitted credential scope;
(k) ALF, AIF, or RBD conditions where required;
(l) provenance or influence restrictions where required;
(m) policy epoch;
(n) revocation conditions;
(o) nonce, expiry, and usage restrictions; and
(p) authorized Finality Sink identity.
For a conjunctive policy:
Vnet = Pidentity AND Pexe AND Pdest AND Pop AND Pscope AND Pstate
where:
Vnet denotes the protected network authorization result;
Pidentity denotes the required workload or requester identity check;
Pexe denotes executable or approved-logic identity validation where
mandatory;
Pdest denotes the required destination validation;
Pop denotes permitted operation-type and request-parameter
validation;
Pscope denotes the applicable purpose and authority-scope validation;
Pstate denotes freshness, revocation, policy-version, and protected-
state validation.
Predicates not required by the particular embodiment may be omitted
according to the applicable Authority Object.
When a mandatory predicate fails, no valid capability is made
available for the rejected network operation.
Das Expires 19 April 2027 [Page 169]
Internet-Draft Protected AI Execution Finality October 2026
11.3.14. WF-03.14 — Protected Grant-State and Evidence Commitment
Upon successful validation, PED-306 performs the protected-state
operation required for the network act.
Such an operation may comprise authorization-grant reservation, nonce
consumption, usage-counter update, capability-state registration, or
another required protected transition.
EV-308 generates or commits the corresponding protected validation
evidence before, or atomically with, capability availability,
according to the applicable embodiment.
A non-limiting protected evidence record comprises:
receipt_id;
operation_id;
descriptor_digest;
authority_reference;
validated_policy_epoch;
destination_scope_reference;
executable_identity_reference;
protected_state_transition;
finality_sink_id;
validation_result;
protected_authentication.
The evidence may be committed as an Egress LAVR, ZK-LAVR,
authenticated record, sealed commitment, or equivalent protected
validation representation.
An ordinary proxy access log created after transmission does not
substitute for a required protected pre-effectuation evidence
commitment.
Das Expires 19 April 2027 [Page 170]
Internet-Draft Protected AI Execution Finality October 2026
11.3.15. WF-03.15 — Scoped Network Egress Capability
CR-309 generates, registers, or releases the scoped network execution
capability after completion of the required protected authorization
transaction.
In an illustrative authenticated-capability implementation, the
capability contains or securely references:
capability_id;
operation_descriptor_digest;
requesting_workload_id;
executable_scope;
destination_scope;
operation_scope;
route_scope;
policy_epoch;
revocation_state_reference;
nonce;
expiry;
usage_limit;
validation_evidence_digest;
finality_sink_id.
The capability may be represented through a signed structure, MAC-
authenticated structure, protected capability table, hardware-
controlled forwarding entry, or other protected enablement mechanism.
The capability is non-bearer when the applicable Finality Sink
enforces the required correspondence between the capability and the
actual operation, requesting context, protected state, permitted
sink, and usage condition.
Das Expires 19 April 2027 [Page 171]
Internet-Draft Protected AI Execution Finality October 2026
Possession of the capability bytes by an unrelated process does not
independently authorize a different operation if the required non-
bearer predicates are enforced.
11.3.16. WF-03.16 — Verification Immediately Before Network
Effectuation
NF-310 receives the proposed network operation and the associated
capability or capability reference.
Before permitting the governed network effect, NF-310 determines the
effectuation-relevant properties of the request actually presented.
The Finality Sink verifies:
(a) the capability authentication;
(b) the actual requesting execution context;
(c) the applicable executable identity;
(d) the actual destination and required resolution state;
(e) the application operation and parameters;
(f) the permitted route where required;
(g) the current mandatory protected authorization state;
(h) the required validation-evidence commitment;
(i) freshness and capability-consumption conditions; and
(j) the designated Finality Sink identity.
An illustrative verification expression is:
PermitNetwork = Auth(C) AND Match(C,Dactual) AND
DestinationValid(C,Tactual) AND StateValid(C,S) AND SinkValid(C,F)
where:
PermitNetwork denotes permission to perform the governed network
effect;
C denotes the scoped network capability;
Dactual denotes the actual operation descriptor;
Das Expires 19 April 2027 [Page 172]
Internet-Draft Protected AI Execution Finality October 2026
Tactual denotes the effectuation-relevant actual destination or
target identity;
S denotes the required protected authorization state;
F denotes the current network Finality Sink;
Auth verifies capability authenticity;
Match verifies exact descriptor equality or expressly authorized
bounded-scope matching;
DestinationValid verifies the required target, route, and destination
restrictions;
StateValid verifies mandatory freshness, revocation, policy, and
usage state;
SinkValid verifies that the capability authorizes the particular
Finality Sink.
The governed operation proceeds only if PermitNetwork is true.
11.3.17. WF-03.17 — Redirection and Multi-Hop Request Control
Where a network operation can trigger an HTTP redirect, service-
discovery change, API relocation, or another destination change, the
system evaluates whether the resulting operation remains within the
authorized scope.
In one implementation, the controlled request executor disables
automatic redirect following unless the redirect-handling component
performs the required verification.
A redirect response proposing a new URL or endpoint is treated as
either:
(a) a bounded continuation of the original authorized operation,
where the original capability expressly permits that class of
destination and operation change; or
(b) a new Candidate Network Act requiring a new or updated protected
authorization event.
The redirect-handling component determines the destination, protocol,
method, resource path, request body, and credential scope applicable
to the subsequent operation.
Das Expires 19 April 2027 [Page 173]
Internet-Draft Protected AI Execution Finality October 2026
Where a redirect changes the required authorized destination, request
method, recipient, or credential-bearing context, the changed
operation does not proceed under an incompatible previous
authorization.
A redirect from an approved public endpoint to an unauthorized
internal service, local interface, cloud metadata endpoint, or
different service identity is refused unless the applicable protected
authorization permits the actual target.
Credentials are not forwarded to a redirected endpoint merely because
the original destination was authorized.
For multiple redirects, each resulting transmission must satisfy the
applicable authorization and effectuation conditions.
The design does not assume that redirect validation at the first
request automatically authorizes an entire future redirect chain.
11.3.18. WF-03.18 — Connection Reuse, HTTP Multiplexing, and Session
Binding
In an embodiment supporting persistent connections, multiple requests
may share an established TCP, TLS, HTTP/2, HTTP/3, QUIC, or
equivalent transport session.
The authorization of the original connection does not automatically
authorize every application operation subsequently transmitted
through that connection.
Where operation-specific authorization is required, each governed
request, stream, message, or bounded transfer unit is associated with
the corresponding protected authorization condition.
If the transport supports connection reuse across multiple service
authorities, the system verifies that the actual operation remains
within its authorized destination and service-identity scope.
Where a session-bound capability is used, the capability may
identify:
session_id;
authorized_service_identity;
source_workload;
permitted_operation_class;
Das Expires 19 April 2027 [Page 174]
Internet-Draft Protected AI Execution Finality October 2026
policy_epoch;
session_freshness;
finality_sink_id.
An approved session may support multiple operations only to the
extent expressly authorized by its protected usage, scope, and
freshness conditions.
If operation-specific validation is mandatory, an existing
authenticated connection cannot substitute for the required per-
operation capability check.
11.3.19. WF-03.19 — Encrypted Traffic and Application-Layer Visibility
The network Finality Sink may operate at a transport layer,
application layer, or combination of layers.
A transport-level enforcement component may verify network addresses,
ports, routing metadata, connection identity, and other information
available at its enforcement point.
An application-level broker may additionally verify HTTP methods, URL
paths, decoded request parameters, request-body digests, or
credential-mediated operations where such information is available
through a trusted interface.
For end-to-end encrypted traffic, a network component that does not
terminate or otherwise legitimately access the encrypted application
session cannot independently inspect the concealed application
fields.
Where those fields form mandatory authorization predicates, the
system uses a trusted application-level request broker, controlled
TLS endpoint, authenticated client-side request representation,
receiving-side verifier, or another suitable enforcement arrangement.
If the required fields cannot be verified, the corresponding
operation is withheld rather than presumed valid.
The use of HTTPS, TLS, QUIC, or another secure transport does not
independently establish that the transmitted operation has obtained
protected execution-finality authorization.
Das Expires 19 April 2027 [Page 175]
Internet-Draft Protected AI Execution Finality October 2026
11.3.20. WF-03.20 — Proxy, Service-Mesh, and Network-Hardware
Alternatives
In one implementation, NF-310 comprises an application-level egress
proxy.
The proxy retains or receives the actual network operation, verifies
the scoped capability, and forwards only the corresponding authorized
request.
In a cloud-native implementation, the network Finality Sink may
comprise a service-mesh sidecar, egress controller, ingress
controller, API gateway, workload proxy, or corresponding service-to-
service enforcement component.
The capability may be bound to a source workload identity,
destination service identity, authenticated transport session, route,
policy epoch, nonce, and validation-evidence reference.
In a hardware-assisted implementation, a SmartNIC or DPU enforces an
authenticated, scoped forwarding grant before permitting the
corresponding network transfer.
A hardware component operating below the application layer may rely
on a trusted broker's authenticated operation classification where
application-specific checks are required.
In a receiving-side implementation, an API gateway or protected
downstream service may act as the Finality Sink for service
invocation or resource commitment.
A source-side network Finality Sink and a receiving-side operation
Finality Sink may control different consequential boundaries.
Authorization for packet transmission does not necessarily establish
authorization for the receiving service to commit a transaction.
11.3.21. WF-03.21 — Time-of-Check and Time-of-Use Protection
The architecture prevents unauthorized substitution between protected
validation and the actual network effectuation event.
Potential substitutions include:
(a) hostname resolution changes;
(b) destination address replacement;
(c) executable replacement;
Das Expires 19 April 2027 [Page 176]
Internet-Draft Protected AI Execution Finality October 2026
(d) changed request method;
(e) modified resource path;
(f) altered request body;
(g) replaced credential scope;
(h) route substitution;
(i) reuse of an authorized transport session for a different
operation; or
(j) change in required policy or revocation state.
Where exact binding is required, the Finality Sink compares the
actual effectuation-relevant state with the validated descriptor
commitment.
An implementation may use immutable request buffers, protected
request identifiers, kernel-managed object handles, authenticated
session references, operation-specific capability entries, and
protected state versions to preserve correspondence.
Where the operation changes materially after authorization, the
previous capability is rejected or renewed validation is required.
The Finality Sink does not rely solely on the fact that an upstream
component previously reported an allow decision.
11.3.22. WF-03.22 — Continuous Network Egress and Rolling Authorization
For a long-running agent session, the system may require successive
network operations to undergo separate protected validation events.
Each operation may produce a corresponding micro-LAVR or update a
protected receipt-chain state.
A stream or transfer may be divided into bounded units, such as
messages, requests, chunks, connection windows, or protocol-defined
operation phases.
Where an embodiment uses a rolling capability, the capability is
bound to a permitted transfer unit or window.
Das Expires 19 April 2027 [Page 177]
Internet-Draft Protected AI Execution Finality October 2026
If the required destination, operation, workload identity, route,
policy, freshness, or runtime-behavior condition becomes invalid, the
PED withholds the next required capability or the Finality Sink
rejects the affected operation.
A previously transmitted unit is not retroactively withdrawn merely
because a subsequent unit fails authorization.
Such streaming authorization does not require inspecting every
transmitted byte when the applicable authorized unit and its verified
bounds are otherwise enforced.
11.3.23. WF-03.23 — Protected Capability Consumption and Retry Handling
Where a network operation is authorized for a bounded number of uses,
NF-310 performs or coordinates the required protected usage-state
verification.
A representative state machine comprises:
PENDING;
AUTHORIZED;
RESERVED;
EFFECTUATION_ATTEMPTED;
CONFIRMED_EFFECTIVE;
DENIED;
INDETERMINATE.
An operation may transition from AUTHORIZED to RESERVED when its
required capability state is consumed or reserved.
The system prevents two concurrent operations from independently
consuming the same single-use authorization.
If the network connection fails before the governed operation is
transmitted, the implementation may permit protected recovery
according to the applicable state rules.
If a request may have reached the remote service but no completion
response is received, the implementation records the relevant
uncertainty.
Das Expires 19 April 2027 [Page 178]
Internet-Draft Protected AI Execution Finality October 2026
A retry does not automatically receive a new independently reusable
capability where duplicate effectuation would violate the authorized
operation scope.
Where a remote system supports authenticated idempotency identifiers,
transaction-status queries, or receiving-side finality enforcement,
those mechanisms may be employed for recovery.
The network gateway cannot generally determine whether every
arbitrary remote service has performed an irreversible operation
merely from the local transmission result.
11.3.24. WF-03.24 — Failure and Fail-Closed Conditions
The protected network Finality Sink refuses effectuation when a
required condition cannot be verified.
Non-limiting denial conditions include:
(a) absent capability;
(b) invalid capability authentication;
(c) unauthorized requester;
(d) executable or tool identity mismatch;
(e) operation-class mismatch;
(f) destination mismatch;
(g) unauthorized address class;
(h) unauthorized redirect;
(i) invalid route binding;
(j) request-method or path mismatch;
(k) request-body substitution;
(l) stale policy epoch;
(m) invalid revocation condition;
(n) expired or replayed nonce;
(o) exhausted usage state;
Das Expires 19 April 2027 [Page 179]
Internet-Draft Protected AI Execution Finality October 2026
(p) validation-evidence mismatch;
(q) unavailable required protected state;
(r) Finality Sink mismatch; or
(s) failure to establish the required canonical operation
correspondence.
The system may retain the Candidate Network Act in a Non-Effective
State, deny it, quarantine it, or submit it for a separately
authorized review procedure.
An ordinary network failure or denial log does not independently
release execution authority.
11.3.25. WF-03.25 — Illustrative End-to-End API Egress Implementation
In one concrete embodiment, an AI agent executes within an isolated
container and proposes an HTTPS POST request to an authorized
enterprise service.
The agent does not possess an unrestricted external network route.
The request is submitted to NI-302 through an authenticated host
broker interface.
The interception component creates an operation identifier, retains
the proposed request in a controlled holding queue, and constructs a
canonical descriptor containing the requesting workload identity,
executable identity, HTTPS protocol, authorized hostname, permitted
destination port, POST method, resource path, request-body digest,
policy epoch, and network Finality Sink identity.
DR-305 resolves the destination through an approved resolver and
identifies the candidate network addresses.
The protected authorization system verifies the required hostname,
address-class, executable, method, resource, purpose, scope, policy,
and freshness predicates.
Following successful validation, the PED performs the required
protected-state operation and commits a corresponding Egress LAVR or
equivalent protected validation record.
The PED then makes available an operation-scoped Sandbox Egress
Capability.
Das Expires 19 April 2027 [Page 180]
Internet-Draft Protected AI Execution Finality October 2026
The network Finality Sink reconstructs or verifies the actual request
and determines the destination selected for connection.
The Finality Sink verifies that the operation-specific capability is
authentic, that the request matches the authorized descriptor, that
the actual destination is permitted, and that the mandatory current
state conditions remain valid.
If verification succeeds, the controlled egress component forwards
the authorized request.
If the destination has changed to a prohibited address, the request
parameters have been modified, the executable identity is
inconsistent, or the policy state is invalid, the egress component
refuses the operation.
If the remote service returns a redirect, the redirect handler
evaluates the resulting request against the original bounded
authorization or submits the resulting operation for renewed
protected validation.
The agent cannot independently transmit the redirected request
through an alternative uncontrolled network path.
This example illustrates an application-level egress embodiment and
may be adapted to other protocols or effectuation interfaces
according to their available verification semantics.
11.3.26. WF-03.26 — PHOSITA Verification and Negative Tests
A person having ordinary skill in operating-system security, network
proxies, API gateways, distributed authorization, cloud networking,
or protected execution systems may test the described arrangement
through the following non-limiting cases.
Test 1 — Exact authorized request: Submit a request whose actual
executable, destination, operation, protected state, and required
bindings match the capability. The Finality Sink permits the scoped
operation.
Test 2 — Executable substitution: Present the same request from a
different executable where executable identity is mandatory. The
request is refused.
Test 3 — Destination substitution: Replace the authorized destination
with a prohibited target after validation. The Finality Sink refuses
transmission.
Das Expires 19 April 2027 [Page 181]
Internet-Draft Protected AI Execution Finality October 2026
Test 4 — DNS rebinding: Cause a hostname previously associated with
an allowed address to resolve or connect to a prohibited address.
The destination-consistency predicate fails.
Test 5 — Unauthorized redirect: Return an HTTP redirect to a
destination outside the permitted scope. The redirected operation is
withheld.
Test 6 — Method or path change: Change an authorized HTTP operation
to another effectuation-relevant method or resource. The descriptor
verification fails where that field is mandatory.
Test 7 — Request-body substitution: Replace a payload whose digest
formed part of the authorization. The actual-operation binding
fails.
Test 8 — Connection reuse: Reuse an authenticated connection for an
operation outside the bound scope. The subsequent operation is
refused.
Test 9 — Capability replay: Re-present a consumed single-use
capability. The protected usage condition fails.
Test 10 — Policy revocation: Advance a required revocation or policy
epoch. An affected capability bound to incompatible earlier state is
rejected.
Test 11 — Proxy bypass: Attempt direct network transmission from the
sandbox through another available interface. The alternative path is
blocked or subjected to equivalent required Finality Sink
verification.
Test 12 — Encrypted opaque request: Present an encrypted request
whose mandatory application-level fields are not verifiable at the
selected enforcement component. The system refuses the operation
unless a suitable trusted verification path is available.
Test 13 — Indeterminate remote completion: Interrupt a connection
after possible request delivery and attempt replay. The protected
recovery procedure prevents an unauthorized duplicate effect.
Test 14 — Concurrent authorization use: Attempt simultaneous
effectuation using a single-use grant. The protected consumption
mechanism permits no more than the authorized usage count.
Das Expires 19 April 2027 [Page 182]
Internet-Draft Protected AI Execution Finality October 2026
The tests may be implemented using controlled sandbox workloads,
programmable network destinations, test proxies, simulated DNS
responses, mock downstream services, fault injection, and protected-
state inspection.
11.3.27. WF-03.27 — Alternative Authorization Granularity
The protected network architecture may operate at different
authorization granularities according to the security requirement and
effectuation semantics.
Per-request authorization: Each governed API request or transmission
requires its own scoped capability.
Per-message authorization: Each externally effective message in a
persistent communication channel is separately authorized.
Per-session authorization: A capability authorizes a defined session
and bounded operation class under specified validity, usage, and
revocation conditions.
Per-transfer-window authorization: A bounded stream segment or
transfer window is authorized using a rolling capability and
protected usage state.
Per-service authorization: A capability permits specified operations
involving an authenticated service identity and permitted operation
scope.
Per-receiving-operation authorization: A receiving-side Finality Sink
verifies an operation-specific capability before performing a
governed downstream commit or consequential action.
An embodiment requiring independent authorization of each
consequential operation does not treat an unrestricted session-level
allow decision as equivalent to operation-specific finality.
11.3.28. WF-03.28 — Structural and Security Variations
The described functions may be distributed among the same or
different protected components.
In a single-node implementation, an enforcement-controlled gateway
may stage a request, obtain protected authorization, commit evidence,
register a scoped capability, and verify that capability at its own
controlled forwarding interface.
Das Expires 19 April 2027 [Page 183]
Internet-Draft Protected AI Execution Finality October 2026
In a separated implementation, a protected authority service performs
validation and capability issuance while a network gateway
independently verifies the capability before transmission.
In a confidential-computing implementation, a protected virtual-
machine or enclave component may perform part of the authorization or
request verification, while a host or hardware network Finality Sink
controls effectuation.
In a hardware-assisted implementation, a SmartNIC, DPU, or protected
network controller may enforce a bounded route or forwarding
authorization.
In a receiving-side implementation, a remote gateway or service may
perform its own operation-specific Finality Sink verification before
completing a protected downstream action.
The choice of software, hardware, firmware, virtualized, or
distributed enforcement substrate does not remove the requirement to
demonstrate that the governed effectuation path is actually
controlled.
11.3.29. WF-03.29 — Technical Effect
The embodiment establishes a protected causal relationship between
the actual network operation and the authority required for that
operation to cross a governed network effectuation boundary.
The relationship comprises:
(a) interception of a proposed network operation;
(b) maintenance in a Non-Effective State;
(c) construction of an effectuation-relevant Candidate Act
Descriptor;
(d) validation of the applicable authority, executable, purpose,
destination, route, operation, and protected-state predicates;
(e) required protected-state handling;
(f) protected validation-evidence commitment;
(g) scoped non-bearer capability availability;
(h) independent verification against the actual network operation at
the applicable Finality Sink; and
Das Expires 19 April 2027 [Page 184]
Internet-Draft Protected AI Execution Finality October 2026
(i) controlled effectuation or fail-closed refusal.
The architecture prevents an upstream request approval, executable
permission, DNS lookup, established network connection, authenticated
transport session, or agent-generated instruction from independently
substituting for the protected operation-specific execution authority
required at the governed Finality Sink.
Computation is not authority to act.
11.4. WF-04 — Transaction-Bound Agent Authorization, Protected Grant-
State Consumption, Credential Broker, and Atomic Credential
Effectuation
11.4.1. WF-04.1 — Technical Purpose
This embodiment provides a computer-implemented protected execution-
finality system for controlling credential-mediated operations
generated or requested by an artificial-intelligence agent, agentic
workflow, autonomous application, or other computational workload.
The embodiment prevents an agent from independently converting
possession of a credential reference, surrogate credential, connector
identifier, service endpoint, or previously granted permission into
unrestricted authority to perform a consequential external operation.
A proposed credential-mediated operation is represented as a
Candidate Act maintained in a Non-Effective State.
A protected authorization mechanism validates the exact or bounded
operation, establishes the required protected grant-state transition,
commits the required authorization evidence, and releases or makes
available a scoped execution-enablement artifact.
A separately controlled credential-effectuation component or Finality
Sink verifies the authorization against the operation actually
presented for effectuation before applying the protected credential.
The architecture separates:
(a) computation and preparation of the proposed operation;
(b) authorization of that particular operation;
(c) protected ownership and application of credential material; and
(d) effectuation of the authorized consequence.
Das Expires 19 April 2027 [Page 185]
Internet-Draft Protected AI Execution Finality October 2026
Successful authentication of the agent or existence of an earlier
service permission does not independently authorize every subsequent
credential-mediated operation.
11.4.2. WF-04.2 — Participating Components
A non-limiting implementation comprises:
AE-401 — Agent Execution Environment
An agent, workflow, tool runtime, container, virtual machine,
application, browser automation environment, or other computational
component configured to request credential-mediated operations.
IM-402 — Operation Interception Component
An enforcement-controlled interface configured to receive proposed
credential-mediated operations before they become externally
effective.
HQ-403 — Non-Effective Operation Holding Mechanism
A controlled queue, staging buffer, protected operation record,
pending request object, or equivalent mechanism retaining proposed
operations pending authorization.
NC-404 — Operation Normalization Component
A component configured to construct a canonical operation descriptor
representing the requested consequential act and its effectuation-
relevant parameters.
PED-405 — Protected Enforcement Domain
A protected authorization component configured to validate the
applicable Authority Object, operation descriptor, authorization
predicates, and protected state.
GS-406 — Protected Grant-State Store
A protected store maintaining operation-specific authorization
grants, authorization-state versions, reservation conditions,
consumption state, validity intervals, revocation conditions, and
corresponding evidence commitments.
EV-407 — Protected Validation-Evidence Component
Das Expires 19 April 2027 [Page 186]
Internet-Draft Protected AI Execution Finality October 2026
A component configured to generate or commit protected authorization
evidence, including a LAVR, Egress LAVR, authenticated receipt,
sealed finality record, or equivalent protected representation.
CR-408 — Scoped Capability Release Component
A protected component configured to release or make available an
operation-scoped, non-bearer execution capability.
CS-409 — Protected Credential Store
A protected credential repository, hardware security module, secure
enclave, secret-management service, operating-system credential
service, or equivalent protected key or credential facility.
CE-410 — Credential-Effectuation Component
A credential broker, privileged connector, authenticated proxy, host
worker, secure signing service, gateway, or equivalent component
having controlled access to credential-mediated operations.
VS-411 — Execution-Verification Component
A mechanism configured to verify correspondence between the operation
presented for effectuation, its canonical authorization descriptor,
current grant state, and scoped execution capability.
FS-412 — Credential or External-Operation Finality Sink
An enforcement-controlled boundary at which the protected credential
is applied, released for bounded use, or made capable of producing
the governed external operation.
OS-413 — Protected Outcome-State Component
A component maintaining operation-specific completion, denial,
reservation, uncertainty, and recovery information.
The components may be integrated within one protected host,
implemented within hardware or firmware, or distributed across
authenticated execution environments.
The protected credential store, execution verifier, and Finality Sink
may be colocated where their required independent functional
verification and protected control are preserved.
Das Expires 19 April 2027 [Page 187]
Internet-Draft Protected AI Execution Finality October 2026
11.4.3. WF-04.3 — Credential and Authorization Separation
Before processing credential-mediated operations, the system
establishes two distinguishable authorities.
The first is authority to request or prepare a proposed operation.
The second is protected authority to apply credential material or
invoke a credential-mediated effectuation interface for a validated
operation.
An AI agent may know:
(a) a connector name;
(b) an authorized service category;
(c) a non-authoritative credential reference;
(d) an available API endpoint;
(e) a permitted task description; or
(f) a previously approved operation class.
Such knowledge or possession does not independently confer
unrestricted use of the protected credential.
Protected credential material may comprise an OAuth access token, API
credential, private signing key, client certificate, service-account
credential, authentication assertion, payment authorization
credential, cloud-service credential, or equivalent authorization
material.
The selected implementation controls both access to the credential
and its actual use.
11.4.4. WF-04.4 — Establishment of Protected Credential Custody
CS-409 maintains the reusable protected credential outside the
execution authority controlled by AE-401.
In one implementation, CS-409 comprises a host-side secret-management
service protected by operating-system isolation and authenticated
service interfaces.
Das Expires 19 April 2027 [Page 188]
Internet-Draft Protected AI Execution Finality October 2026
In another implementation, the credential is held within a hardware
security module, secure enclave, protected virtual machine, or
equivalent protected boundary.
Where a credential is exportable, the system restricts its delivery
to an authorized credential-effectuation component.
Where the credential is non-exportable, the protected store may
perform an authorized signing, encryption, authentication, or other
credential-backed operation without disclosing the underlying secret.
The credential store associates protected material with metadata that
may identify:
credential_id;
authorized_service;
credential_scope;
permitted_tenant;
credential_version;
revocation_epoch;
validity_interval;
permitted_executor;
key_usage_class.
Such metadata does not necessarily expose the underlying credential.
11.4.5. WF-04.5 — Non-Authoritative Credential Reference
In an embodiment employing surrogate credentials, AE-401 receives a
non-authoritative reference rather than reusable protected credential
material.
The reference may comprise:
(a) an opaque credential identifier;
(b) a connector-specific credential placeholder;
(c) a session-associated surrogate reference;
Das Expires 19 April 2027 [Page 189]
Internet-Draft Protected AI Execution Finality October 2026
(d) a non-secret credential selection value; or
(e) another identifier resolvable only through the protected
credential-effectuation system.
An illustrative agent-visible reference is:
credential_ref = "service-credential-reference-17"
The reference identifies a protected credential or permitted
credential class but is not itself accepted by the external service
as a reusable credential.
The mapping between the reference and protected credential material
is controlled by CE-410 or CS-409.
Possession of the reference does not permit the agent to retrieve the
underlying secret or to issue unrestricted operations.
The reference may be bound to a tenant, workload, session, or
permitted connector according to the applicable embodiment.
11.4.6. WF-04.6 — Candidate Credential-Mediated Act Generation
AE-401 generates or prepares a proposed operation requiring
credential-mediated authority.
Such operations may include:
(a) creating a cloud resource;
(b) updating a customer record;
(c) transmitting a confidential document;
(d) initiating an authorized commerce transaction;
(e) modifying an enterprise repository;
(f) invoking a privileged API;
(g) sending an authenticated communication;
(h) publishing an artifact;
(i) performing an authenticated service operation; or
(j) another consequential credential-mediated request.
Das Expires 19 April 2027 [Page 190]
Internet-Draft Protected AI Execution Finality October 2026
The proposed operation is classified as Candidate Credential-Mediated
Act CA-414.
The operation may also constitute a Candidate Sandbox Egress Act
under the broader sandbox-egress architecture.
The agent's preparation of CA-414 does not independently authorize
credential application or external effectuation.
11.4.7. WF-04.7 — Interception and Non-Effective State
IM-402 receives CA-414 and places the operation into HQ-403.
The operation is maintained as a pending, non-effective request.
An illustrative staging record comprises:
operation_id;
agent_identity;
workload_identity;
credential_reference;
connector_identity;
requested_operation;
destination_service;
operation_parameters_reference;
requested_permission_scope;
policy_epoch;
status = PENDING.
The interception component prevents the operation from reaching a
credential-effectuation interface capable of completing the governed
act until the required protected conditions have been satisfied.
The agent cannot bypass the interception mechanism by independently
using the protected credential or invoking an unrestricted
alternative privileged connector.
Das Expires 19 April 2027 [Page 191]
Internet-Draft Protected AI Execution Finality October 2026
11.4.8. WF-04.8 — Canonical Operation Descriptor
NC-404 constructs a canonical descriptor representing the proposed
consequential operation.
The descriptor includes effectuation-relevant information required to
distinguish authorized from unauthorized operations.
A non-limiting descriptor comprises:
operation_id;
requesting_agent_identity;
workload_identity;
connector_identity;
operation_class;
destination_service;
destination_endpoint;
request_method;
resource_identifier;
operation_parameters;
request_payload_digest;
credential_scope;
protected_grant_identifier;
policy_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_identifier.
Das Expires 19 April 2027 [Page 192]
Internet-Draft Protected AI Execution Finality October 2026
The descriptor may additionally identify a human approval artifact,
permitted purpose, provenance requirement, approved tool identity, or
other mandatory authority condition.
A deterministic encoding procedure produces the canonical
representation.
An illustrative mathematical expression is:
D = Canon_v(ID, OP, T, P, K, X, E, F)
where:
D denotes the canonical operation descriptor;
Canon_v denotes a deterministic encoding procedure with version
identifier v;
ID denotes the authenticated requesting identity;
OP denotes the proposed operation class;
T denotes the intended destination or effectuation target;
P denotes the effectuation-relevant parameters;
K denotes the required credential or permission scope;
X denotes the requesting execution context;
E denotes the applicable protected authorization-state epoch;
F denotes the designated Finality Sink.
The particular implementation defines which fields are mandatory.
A cryptographic descriptor digest may be computed as:
hD = H("DAS-CREDENTIAL-ACT-v1" || Encode(D))
where:
hD denotes the descriptor digest;
H denotes a cryptographic hash function;
Encode denotes the specified deterministic byte encoding;
Das Expires 19 April 2027 [Page 193]
Internet-Draft Protected AI Execution Finality October 2026
|| denotes concatenation;
"DAS-CREDENTIAL-ACT-v1" denotes an illustrative domain-separation
label.
The encoding prevents ambiguous field boundaries or incompatible
descriptor interpretations.
11.4.9. WF-04.9 — Normalization and Actual-Operation Correspondence
The operation-normalization component interprets the request
according to the effectuation semantics of the intended credential-
mediated service.
For an HTTP operation, the normalized representation may bind the
intended service, request method, resource path, query parameters,
authenticated tenant, request-body digest, and authorized credential
scope.
For a signing operation, the representation may bind the exact
document or message digest and permitted signing purpose.
For a database connector, the representation may bind the permitted
statement class, target table, record identity, and approved mutation
parameters.
The operation descriptor identifies the attributes that materially
determine the external effect.
The authorization system does not rely solely upon a free-form
natural-language description such as "update the account" or "send
the approved information."
Where a downstream executor could interpret the request differently
from the authorizer, the system uses a shared canonical operation
representation, an authenticated normalized request object, or a
verified reconstruction procedure.
An authorization for one operation cannot be reused for a materially
different operation when the changed parameter is part of the
mandatory authorization binding.
11.4.10. WF-04.10 — Protected Authority Object
PED-405 obtains the Authority Object applicable to CA-414.
The Authority Object may identify:
Das Expires 19 April 2027 [Page 194]
Internet-Draft Protected AI Execution Finality October 2026
(a) permitted agent or workload identities;
(b) authorized purpose;
(c) permitted connector or service;
(d) allowed operation class;
(e) resource and recipient restrictions;
(f) credential scope;
(g) transaction limits;
(h) validity interval;
(i) approved execution context;
(j) required human approval;
(k) applicable policy epoch;
(l) protected revocation conditions;
(m) nonce or usage restrictions; and
(n) Finality Sink identity.
Where a Sandbox Egress Authority Object applies, the protected
validation may additionally evaluate the applicable AIF, ALF, RBD,
destination, provenance, and runtime-behavior predicates.
PED-405 verifies the required authenticity and state of the Authority
Object.
An earlier agent-facing approval or credential reference does not
independently establish the protected authority required for CA-414.
11.4.11. WF-04.11 — Protected Authorization Predicates
PED-405 evaluates the applicable authorization predicates.
For a conjunctive authorization policy, the result may be expressed
as:
V = Pid AND Pop AND Ptarget AND Pscope AND Pgrant AND Pstate
where:
Das Expires 19 April 2027 [Page 195]
Internet-Draft Protected AI Execution Finality October 2026
V denotes the protected authorization result;
Pid verifies the requesting identity and execution context;
Pop verifies the requested operation class;
Ptarget verifies the intended destination, recipient, or target;
Pscope verifies the permitted credential and authority scope;
Pgrant verifies the applicable protected grant and usage conditions;
Pstate verifies mandatory policy, revocation, freshness, and
protected-state conditions.
Additional predicates may include approval, provenance, ALF, AIF,
RBD, tenant, quota, jurisdiction, or other conditions where required.
V equals true only when every mandatory predicate succeeds.
The implementation may support approved alternative or threshold
predicates according to the applicable Authority Object.
If a mandatory predicate fails, the protected system does not issue a
valid credential-effectuation capability for the rejected operation.
11.4.12. WF-04.12 — Protected Authorization-Grant Record
GS-406 maintains an operation-specific grant record.
A representative record comprises:
grant_id;
operation_id;
descriptor_digest;
authorized_requester;
authorized_connector;
authorized_target;
permitted_credential_scope;
valid_from;
Das Expires 19 April 2027 [Page 196]
Internet-Draft Protected AI Execution Finality October 2026
valid_until;
policy_epoch;
revocation_epoch;
usage_limit;
remaining_uses;
grant_state_version;
finality_sink_id;
validation_evidence_reference;
status.
The grant is associated with the particular operation descriptor or
an expressly bounded operation class.
The grant state is not equivalent to a general reusable credential.
The grant may authorize one specific act, a limited number of acts, a
defined session, or a restricted operation window, according to the
applicable authorization.
For a single-use consequential operation, the grant state includes a
condition preventing more than one unauthorized consumption.
11.4.13. WF-04.13 — Protected Grant-State Reservation
Before releasing the capability required for the operation, PED-405
establishes the protected grant-state transition.
In a single-use embodiment, the system checks that:
(a) the grant is valid;
(b) the descriptor matches the grant;
(c) the relevant policy and revocation state remain acceptable;
(d) no incompatible reservation already exists;
(e) the usage allowance remains available; and
(f) the requested operation is within the permitted scope.
Das Expires 19 April 2027 [Page 197]
Internet-Draft Protected AI Execution Finality October 2026
Where the required conditions succeed, the system atomically reserves
or consumes the authorized usage state.
An illustrative operation is:
CAS(G.state, AVAILABLE, RESERVED(operation_id, version + 1))
where:
CAS denotes an atomic compare-and-swap or equivalent protected
compare-and-update procedure;
G denotes the applicable grant record;
AVAILABLE denotes an unreserved valid grant state;
RESERVED denotes a state preventing another incompatible operation
from consuming the same authorization;
operation_id denotes the candidate operation;
version denotes the protected grant-state version.
The state change succeeds only if the actual stored state corresponds
to the required expected state.
If the reservation fails, the capability is withheld and the system
does not assume that the operation remains authorized.
This procedure may be implemented through protected transactional
storage, a secure monotonic state mechanism, an HSM-controlled state
service, or equivalent protected machinery.
11.4.14. WF-04.14 — Concurrency and Double-Consumption Prevention
Where two or more operations attempt to consume the same restricted
grant, the protected state store serializes or otherwise coordinates
the required consumption transition.
For a single-use grant, at most one incompatible operation may
establish the required valid reservation.
Suppose two concurrent operations A and B reference the same
authorization state version.
Both may independently read the initial AVAILABLE state, but the
protected compare-and-update procedure permits only one transition to
the required RESERVED state.
Das Expires 19 April 2027 [Page 198]
Internet-Draft Protected AI Execution Finality October 2026
The losing request is denied, retried against updated protected state
where permitted, or subjected to renewed authorization.
The implementation does not treat two successful preliminary read
checks as two valid grant consumptions.
Where the authorization permits multiple uses, the protected
mechanism enforces the corresponding usage budget or counter rather
than requiring single use.
11.4.15. WF-04.15 — Protected Validation-Evidence Commitment
Following successful validation and coordinated with the required
grant-state transition, EV-407 generates or commits protected
validation evidence.
The evidence may identify:
receipt_id;
operation_id;
descriptor_digest;
grant_id;
prior_grant_state_version;
committed_grant_state_version;
authorization_predicate_reference;
credential_scope;
finality_sink_id;
policy_epoch;
revocation_epoch;
nonce;
decision;
protected_authentication.
The evidence may comprise a LAVR, Egress LAVR, sealed receipt,
authenticated commitment, or equivalent protected finality record.
Das Expires 19 April 2027 [Page 199]
Internet-Draft Protected AI Execution Finality October 2026
The required evidence is committed before, or atomically with, making
the corresponding execution capability available.
A log written merely after credential application does not replace
mandatory pre-effectuation evidence commitment.
11.4.16. WF-04.16 — Protected Credential-Finality Transaction
In one implementation, protected authorization, grant-state
reservation, evidence commitment, and capability availability are
coordinated through a protected finality transaction.
An illustrative transaction is:
(Snext, R, Ready) = CommitGrant(D, A, Scurrent, G, F)
where:
Snext denotes the protected state after successful commitment;
R denotes the protected validation-evidence commitment;
Ready denotes the protected result indicating that required pre-
release conditions have been satisfied;
D denotes the canonical operation descriptor;
A denotes the applicable authenticated authority;
Scurrent denotes the prior protected authorization state;
G denotes the operation-specific grant;
F denotes the intended Finality Sink.
The transaction does not make an execution capability usable when the
required protected commitment is absent or incomplete.
In a two-phase implementation, the system first creates a protected
PREPARED record and then commits the required protected-state and
evidence relationships.
Only the committed state supports the corresponding capability.
This atomicity concerns the required protected authorization and
capability-release dependency. It does not necessarily mean that an
arbitrary remote external service participates in the same atomic
storage transaction.
Das Expires 19 April 2027 [Page 200]
Internet-Draft Protected AI Execution Finality October 2026
11.4.17. WF-04.17 — Scoped Credential-Effectuation Capability
CR-408 generates, registers, or releases an operation-scoped, non-
bearer capability.
In an illustrative authenticated implementation, the capability
contains or securely references:
capability_id;
canonical_descriptor_digest;
grant_id;
grant_state_version;
authorized_connector;
authorized_credential_scope;
authorized_destination;
permitted_operation;
validation_evidence_digest;
policy_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_id.
The capability may be cryptographically signed or MAC-authenticated,
maintained as a protected capability-table entry, or implemented
through another protected enablement mechanism.
The capability is not an unrestricted bearer credential.
Its use remains dependent upon the actual operation, permitted
execution context, grant state, authorization scope, designated
Finality Sink, and required freshness conditions.
Das Expires 19 April 2027 [Page 201]
Internet-Draft Protected AI Execution Finality October 2026
An entity possessing the capability representation cannot
successfully employ it for a different operation when the required
non-bearer checks are enforced.
11.4.18. WF-04.18 — Authenticated Credential-Executor Interface
CE-410 communicates with PED-405, CS-409, or VS-411 through an
authenticated inter-component interface.
The interface may comprise an authenticated local IPC channel,
protected host-service channel, mutually authenticated transport
connection, secure enclave call, HSM session, or equivalent
controlled communication path.
Where the embodiment requires executor identity verification, the
protected authorization system validates the identity or attestation
of CE-410.
The relevant identity may comprise:
(a) an authenticated host-service identity;
(b) a registered connector identity;
(c) a verified workload identity;
(d) a protected process identity;
(e) a signed or measured executable identity;
(f) a confidential-computing attestation measurement; or
(g) another machine-verifiable executor identity.
An attestation may be required where specified by the applicable
Authority Object.
The system does not assume that every connector requires hardware
attestation.
An unauthorized connector cannot invoke credential effectuation
merely by copying an approved connector's name or submitting an
agent-visible reference.
11.4.19. WF-04.19 — Independent Verification of the Actual Operation
VS-411 obtains the operation actually presented by CE-410 for
credential-mediated effectuation.
Das Expires 19 April 2027 [Page 202]
Internet-Draft Protected AI Execution Finality October 2026
It constructs or verifies the corresponding actual-operation
descriptor.
Let:
Dactual = Canon_v(ActualRequest, ExecutorContext, TargetSink)
where:
Dactual denotes the descriptor representing the operation actually
presented for effectuation;
Canon_v denotes the specified deterministic canonicalization
procedure;
ActualRequest denotes the effectuation-relevant request fields;
ExecutorContext denotes the authenticated requesting executor and
workload context;
TargetSink denotes the applicable credential or external-operation
Finality Sink.
Where exact descriptor equality is mandatory:
H(Dactual) = hD
where H denotes the specified cryptographic hash function and hD
denotes the validated descriptor digest using the same agreed
encoding and domain separation.
Where bounded variations are expressly authorized, the verifier
checks the required exact fields together with the permitted bounded-
scope conditions.
The verifier additionally checks the current protected grant-state
version and applicable usage, revocation, expiry, and freshness
conditions.
The existence of an earlier protected allow decision does not
eliminate this verification step.
11.4.20. WF-04.20 — Finality Sink Verification Predicate
The final credential-effectuation authorization may be represented
as:
PermitCredential =
Das Expires 19 April 2027 [Page 203]
Internet-Draft Protected AI Execution Finality October 2026
Auth(C)
AND Match(C,Dactual)
AND GrantValid(C,G)
AND ExecutorValid(C,E)
AND ScopeValid(C,K,T)
AND StateValid(C,S)
AND SinkValid(C,F)
where:
PermitCredential denotes permission to apply the protected credential
for the governed operation;
C denotes the scoped execution capability;
Dactual denotes the actual-operation descriptor;
G denotes the current protected grant-state record;
E denotes the verified credential-executor identity;
K denotes the authorized credential scope;
T denotes the actual effectuation target;
S denotes the required protected policy, revocation, freshness, and
usage state;
F denotes the applicable Finality Sink;
Auth verifies capability authenticity;
Match verifies required descriptor correspondence;
GrantValid verifies the required grant reservation or consumption
state;
ExecutorValid verifies the executor identity or attestation required
by the embodiment;
ScopeValid verifies permitted credential use, operation class, and
destination;
Das Expires 19 April 2027 [Page 204]
Internet-Draft Protected AI Execution Finality October 2026
StateValid verifies mandatory protected authorization state;
SinkValid verifies the authorized Finality Sink identity.
The credential-effectuation operation proceeds only when
PermitCredential is true.
11.4.21. WF-04.21 — Protected Credential Selection and Release
Upon successful Finality Sink verification, CE-410 resolves the
authorized credential reference against CS-409.
The resolved credential must correspond to the validated service,
credential scope, tenant, operation class, and required grant state.
The protected credential store may return:
(a) a narrowly scoped credential;
(b) a short-lived delegated credential;
(c) an operation-bound credential-use authorization;
(d) a protected signing result;
(e) a non-exportable cryptographic operation result; or
(f) an internally applied credential operation.
The choice depends upon the selected credential technology.
Where the embodiment requires that reusable protected credential
material remain outside the agent environment, CE-410 does not return
the reusable secret to AE-401.
Credential selection or release for an authorized operation does not
permit applying that credential to a different operation.
11.4.22. WF-04.22 — Surrogate Credential Substitution Variant
In a surrogate-credential embodiment, the agent constructs an
operation using a non-authoritative credential placeholder.
The placeholder is resolved only within an authenticated, trusted
credential-effectuation component after the required authorization
conditions have succeeded.
An illustrative sequence is:
Das Expires 19 April 2027 [Page 205]
Internet-Draft Protected AI Execution Finality October 2026
AE-401 submits a proposed operation identifying a surrogate
credential reference.
IM-402 intercepts and stages the operation.
NC-404 constructs the canonical operation descriptor.
PED-405 validates the applicable Authority Object and protected grant
state.
GS-406 performs the required protected reservation or consumption.
EV-407 commits the protected validation evidence.
CR-408 releases the scoped execution capability.
VS-411 verifies the actual operation against the capability and
protected grant state.
CE-410 resolves the surrogate credential reference within its
protected execution boundary.
CE-410 applies the authorized real credential to the corresponding
validated operation.
FS-412 permits the governed effect only after its required
verification succeeds.
The surrogate itself is not treated as execution authority.
If the operation differs from the authorized descriptor, the
credential is not applied.
If the credential has been revoked or its scope has changed
incompatibly, the operation is rejected or revalidated.
The real credential is not returned to the sandboxed agent.
11.4.23. WF-04.23 — Binding Credential Substitution to the Exact
Request
Where a credential is inserted into an HTTP or API request after
protected authorization, the implementation distinguishes ordinary
application request fields from the protected credential field to be
supplied by CE-410.
The canonical request descriptor may bind:
Das Expires 19 April 2027 [Page 206]
Internet-Draft Protected AI Execution Finality October 2026
(a) the requesting workload;
(b) the authenticated connector identity;
(c) the destination service;
(d) the HTTP method;
(e) the resource path;
(f) the effectuation-relevant request-body digest;
(g) the authorized credential scope;
(h) the protected grant-state version; and
(i) the designated Finality Sink.
The protected credential field may be represented by a credential-
reference identifier and required scope, rather than its undisclosed
secret bytes.
CE-410 is permitted to replace only the designated credential
placeholder or protected authentication field.
The remaining mandatory effectuation-relevant request fields remain
bound to the authorized descriptor.
The final outgoing request is checked for unauthorized mutation
before transmission.
Where the remote protocol requires a signature or authentication
value over the completed request, the signature or authentication
material is produced for the validated request under the permitted
credential scope.
An implementation does not assume that arbitrary credential insertion
leaves every protocol's request semantics unchanged.
11.4.24. WF-04.24 — Redirect and Credential-Leakage Prevention
Where the credential-mediated operation involves network
transmission, the Finality Sink verifies the applicable destination
before applying or transmitting credential material.
A redirect, destination substitution, service-identity mismatch,
routing change, or unauthorized connector substitution is evaluated
against the original authorized operation.
Das Expires 19 April 2027 [Page 207]
Internet-Draft Protected AI Execution Finality October 2026
If the new target is outside the permitted credential scope, the
credential is not forwarded.
In a protected proxy implementation, redirect following may be
disabled unless the resulting operation is separately validated or
expressly permitted within a bounded authorization.
The protected component must not transmit reusable credential
material to an unauthorized destination merely because the original
operation had been approved.
This destination consistency mechanism may operate together with
Workflow WF-03.
11.4.25. WF-04.25 — Atomic Credential Application and Effectuation
Boundary
The term atomic credential application refers, in this embodiment, to
a protected relationship among the required grant-state transition,
operation-specific authorization commitment, capability verification,
and credential-use enablement.
For example, CE-410 may maintain a controlled request state in which
the credential cannot be applied until VS-411 verifies a committed
authorization record and its associated capability.
The request is then passed to the designated Finality Sink through an
enforcement-controlled path.
Where the credential-use operation itself is performed within an HSM
or protected signing module, the module may require the validated
operation digest and authorization reference before producing the
signature.
Where the credential is used to transmit a request to a remote
service, local protected authorization commitment and remote
transaction completion are not presumed to form one globally atomic
transaction.
The implementation may use a protected reservation before
transmission and an outcome-state update after receiving suitable
completion evidence.
The absence of a remote completion response does not prove that the
remote operation failed.
Das Expires 19 April 2027 [Page 208]
Internet-Draft Protected AI Execution Finality October 2026
11.4.26. WF-04.26 — Protected Effectuation Outcome State
OS-413 maintains an operation-specific outcome record.
An illustrative state machine comprises:
PENDING;
VALIDATING;
AUTHORIZED;
RESERVED;
EFFECTUATION_IN_PROGRESS;
CONFIRMED_EFFECTIVE;
DENIED;
INDETERMINATE.
A Candidate Act initially enters PENDING.
Successful authorization may advance it to AUTHORIZED.
A valid protected grant reservation may advance it to RESERVED.
Invocation of the controlled credential-effectuation interface may
advance it to EFFECTUATION_IN_PROGRESS.
Where sufficient completion evidence is obtained, the operation may
transition to CONFIRMED_EFFECTIVE.
Where a mandatory condition fails before effectuation, the operation
may be marked DENIED.
Where external completion cannot be established after a possible
effectuation attempt, the operation is marked INDETERMINATE.
The system distinguishes a reserved authorization from a confirmed
external consequence.
The protected outcome record may identify:
operation_id;
grant_id;
Das Expires 19 April 2027 [Page 209]
Internet-Draft Protected AI Execution Finality October 2026
capability_id;
external_transaction_reference;
effectuation_attempt_count;
last_known_completion_state;
protected_state_version;
recovery_requirement.
11.4.27. WF-04.27 — Crash Recovery and Duplicate-Effect Prevention
If PED-405 fails before the protected grant-state and evidence
commitment is established, no externally usable capability is made
available for the incomplete transaction.
If the protected commitment succeeds but capability delivery fails,
the system consults the committed authorization state before deciding
whether the original capability can be recovered or safely retired.
If CE-410 fails before applying the protected credential, the system
reconciles the reserved grant state and validates whether the
corresponding operation can be resumed.
If CE-410 fails after transmitting a credential-mediated request but
before receiving a response, OS-413 records an indeterminate
completion condition where appropriate.
A subsequent attempt using the same operation identifier is evaluated
against the protected outcome state.
Where a previously completed operation would be duplicated by replay,
a new authorization is withheld unless an applicable recovery
predicate establishes that the additional attempt is permitted.
A downstream idempotency key, transaction-status query, authenticated
receipt, or receiving-side Finality Sink may support reconciliation
where available.
The system does not assert unconditional exactly-once completion
across arbitrary remote services lacking suitable completion or
idempotency facilities.
Das Expires 19 April 2027 [Page 210]
Internet-Draft Protected AI Execution Finality October 2026
11.4.28. WF-04.28 — Human Approval as a Protected Predicate
Where the operation requires human authorization, the proposed
credential-mediated operation remains non-effective pending receipt
of an applicable approval artifact.
The approval artifact may identify the requesting user or operator,
the operation descriptor, permitted recipient, credential scope,
transaction limit, validity interval, and authorization-state
reference.
PED-405 verifies the artifact according to the required authority
conditions.
An approval for one operation does not independently authorize a
materially different operation.
The approval artifact is an input to protected validation and does
not itself substitute for the required grant-state commitment, scoped
capability, and Finality Sink verification.
11.4.29. WF-04.29 — Multiple Credential and Effectuation Boundaries
A governed workflow may contain more than one consequential
credential-related boundary.
For example, one boundary may authorize a protected signing operation
while another controls network transmission of the signed request.
A further receiving-side boundary may control whether the remote
service commits the requested transaction.
Where separate Finality Sinks are required, each sink verifies the
scoped capability or the capability expressly bound to its permitted
stage.
Authorization to generate a signature does not automatically
authorize transmission to every destination.
Authorization to transmit a signed request does not automatically
establish receiving-side authority to commit a separate consequential
operation.
Where the selected embodiment uses one protected component to perform
multiple Finality Sink functions, the component enforces the required
operation-specific conditions for each governed effect.
Das Expires 19 April 2027 [Page 211]
Internet-Draft Protected AI Execution Finality October 2026
11.4.30. WF-04.30 — Illustrative End-to-End Enterprise API
Implementation
In a concrete non-limiting embodiment, an AI agent is authorized to
assist an enterprise user with creating invoices through an external
accounting service.
The agent runs within an isolated execution environment and does not
possess the accounting service's reusable API credential.
Instead, the agent is provided with a non-authoritative credential
reference identifying the permitted accounting connector.
The agent prepares an HTTP POST operation directed to an invoice-
creation endpoint.
The operation includes a recipient identifier, currency, invoice
amount, item description, and an authorized tenant context.
The request is intercepted before network transmission.
The interception component places the operation in a Non-Effective
State and constructs a canonical descriptor including the requesting
workload identity, connector identity, destination service, POST
operation, recipient, amount, invoice data digest, credential scope,
policy epoch, and Finality Sink identity.
The PED obtains the applicable Authority Object and validates the
requested operation.
The predicates may include:
(a) whether the requesting agent is permitted to use the accounting
connector;
(b) whether the invoice-recipient scope is authorized;
(c) whether the requested amount is within the permitted limit;
(d) whether the operation remains within the authorized user purpose;
(e) whether the required approval artifact is valid;
(f) whether the credential scope permits invoice creation;
(g) whether the current policy and revocation conditions remain
valid; and
Das Expires 19 April 2027 [Page 212]
Internet-Draft Protected AI Execution Finality October 2026
(h) whether the corresponding grant has sufficient remaining usage
authority.
Upon successful validation, the protected grant-state store
atomically reserves the operation-specific grant.
The protected validation-evidence mechanism commits an authenticated
record binding the operation descriptor, authorized scope, grant-
state version, and designated Finality Sink.
The capability-release component then makes available an operation-
scoped non-bearer execution capability.
The privileged accounting connector authenticates to the protected
authority and presents the actual invoice-creation operation to the
execution verifier.
The execution verifier compares the operation with the validated
descriptor and checks the current protected grant state.
If all required conditions succeed, the connector retrieves or uses
the protected accounting credential.
The connector applies the credential only to the validated invoice-
creation request and transmits that request through the governed
network Finality Sink.
If the recipient changes, amount changes outside the permitted
authorization, credential scope becomes invalid, or protected grant
state no longer corresponds to the committed transaction, the
operation is refused.
If the accounting service returns a confirmed invoice identifier, the
protected outcome-state record may be updated to CONFIRMED_EFFECTIVE.
If the network response is lost after possible request transmission,
the operation is marked INDETERMINATE until an authorized
reconciliation procedure establishes the applicable result.
The agent cannot resolve the credential reference into the reusable
protected API credential or independently create a different invoice
through the governed connector.
11.4.31. WF-04.31 — Alternative Credential Implementations
The described protected credential-effectuation relationship may be
implemented through different credential technologies.
Das Expires 19 April 2027 [Page 213]
Internet-Draft Protected AI Execution Finality October 2026
OAuth-based implementation: A protected connector applies an access
token whose service, scope, validity, and permitted operation satisfy
the protected authorization conditions.
API-key implementation: The reusable API key is maintained outside
the agent environment, and an authenticated executor applies it only
after operation-specific authorization.
Hardware signing implementation: An HSM performs a signing operation
for an authorized message digest after required capability
verification.
Mutual-TLS implementation: A protected component uses a client
authentication key or certificate within the authorized connection
and service scope.
Short-lived delegated credential implementation: A protected
component obtains a restricted credential valid for the specific
authorized operation, resource, or interval.
Confidential-VM implementation: Credential processing occurs within
an attested confidential workload, subject to the required protected
authorization and effectuation conditions.
Single-node implementation: A protected controller implements grant-
state reservation, evidence commitment, capability checking, and
credential application within one protected node.
Distributed implementation: The PED and privileged connector operate
on different nodes and exchange authenticated operation-specific
authorization information.
These alternatives do not require identical cryptographic protocols
or hardware substrates, but each implementation must enforce the
security properties required by its corresponding claim.
11.4.32. WF-04.32 — PHOSITA Verification and Negative Tests
A person having ordinary skill in distributed authorization, API
security, cryptography, secret management, transactional storage,
cloud infrastructure, or trusted execution systems may verify the
embodiment through controlled tests.
Test 1 — Authorized operation: Submit an operation matching the
authorized descriptor and protected grant state. Credential-mediated
effectuation is permitted.
Das Expires 19 April 2027 [Page 214]
Internet-Draft Protected AI Execution Finality October 2026
Test 2 — Surrogate without authority: Present a valid-looking
credential reference without the required operation-specific
authorization. Effectuation is refused.
Test 3 — Destination substitution: Change the target service after
authorization. The credential is not applied to the unauthorized
destination.
Test 4 — Parameter substitution: Modify a required transaction
parameter. Descriptor correspondence fails.
Test 5 — Wrong connector: Present the capability through an
unauthorized executor when executor identity is mandatory.
Effectuation is refused.
Test 6 — Concurrent grant consumption: Submit two requests against a
single-use grant. The protected state mechanism prevents
unauthorized duplicate consumption.
Test 7 — Stale grant version: Present a capability referencing an
incompatible earlier grant-state version. Verification fails.
Test 8 — Revoked credential: Revoke or invalidate a mandatory
credential or authority condition. Affected operations are refused
pending valid reauthorization.
Test 9 — Credential leakage: Inspect agent-visible responses, logs,
and accessible process state to verify that reusable protected
credentials are not exposed by the selected implementation.
Test 10 — Connector bypass: Attempt direct invocation of the
protected credential service without the required authenticated
executor and operation-specific capability. The request is refused.
Test 11 — Crash before protected commit: Interrupt the protected
authorization transaction before commitment. No valid externally
usable capability becomes available.
Test 12 — Crash after transmission: Interrupt the connector after
possible external effectuation. The operation enters an appropriate
indeterminate or reconciled state rather than automatically receiving
unrestricted retry authority.
Test 13 — Redirect: Attempt to forward a protected credential to a
redirected unauthorized destination. The transmission is refused.
Das Expires 19 April 2027 [Page 215]
Internet-Draft Protected AI Execution Finality October 2026
Test 14 — Replayed capability: Re-present a consumed single-use
capability. The protected consumption predicate rejects unauthorized
reuse.
Test 15 — Human approval mismatch: Supply approval for a different
operation or recipient. The protected authorization predicate fails.
Test 16 — Remote reconciliation: Simulate a lost response to a
transaction supported by a remote idempotency identifier. Verify
that retry or reconciliation follows the protected operation-state
rules without causing an unauthorized duplicate effect.
11.4.33. WF-04.33 — Technical Result
The embodiment establishes a protected operation-specific dependency
between:
(a) a proposed credential-mediated Candidate Act;
(b) interception and Non-Effective State staging;
(c) canonical operation-descriptor construction;
(d) protected authority-predicate validation;
(e) protected authorization-grant state;
(f) required atomic reservation or consumption;
(g) protected validation-evidence commitment;
(h) operation-scoped non-bearer capability availability;
(i) independent executor and actual-operation verification;
(j) controlled protected credential use;
(k) Finality Sink enforcement; and
(l) protected effectuation-outcome handling.
The resulting architecture prevents an agent from converting
possession of a credential reference, connector name, reusable
service permission, or earlier allow decision into unrestricted
execution authority.
Protected credential custody and protected operation-specific
execution authority remain distinguishable.
Das Expires 19 April 2027 [Page 216]
Internet-Draft Protected AI Execution Finality October 2026
The architecture permits different software, firmware, hardware,
cryptographic, and distributed implementations while retaining the
applicable protected finality dependency.
Computation is not authority to act.
Credential possession or reference is not authority to effectuate an
unvalidated operation.
11.5. WF-05 — Privileged Connector Isolation, Authenticated Inter-
Component Communication, Independent Executor Verification, and
Cross-Component Finality Consistency
11.5.1. WF-05.1 — Technical Purpose
This embodiment describes a protected execution-finality architecture
for governing consequential operations requested by an artificial-
intelligence agent and performed through one or more privileged
connectors, protected host workers, service gateways, credential
brokers, application programming interfaces, or equivalent effect-
capable execution components.
The architecture separates the computational environment preparing a
proposed operation from the privileged component capable of
effectuating that operation.
A proposed operation is classified as a Candidate Act and maintained
in a Non-Effective State until the required protected authorization
predicates, protected-state conditions, validation-evidence
commitment, and scoped execution-capability requirements have been
satisfied.
A privileged connector does not treat a request from an agent,
possession of a credential reference, an earlier authorization
result, or access to an authenticated communication channel as
sufficient authority to perform an externally effective operation.
Instead, the connector independently verifies an operation-specific
authorization commitment, execution-enablement artifact, or scoped
capability against the operation actually presented for effectuation
and the applicable current protected state.
Where multiple protected components participate, the system maintains
the required consistency of Candidate Act identity, authorization
scope, policy state, capability-consumption state, and effectuation-
boundary identity.
Das Expires 19 April 2027 [Page 217]
Internet-Draft Protected AI Execution Finality October 2026
The protected arrangement prevents an untrusted agent from using a
privileged connector as a means of circumventing execution-finality
enforcement.
11.5.2. WF-05.2 — Participating Technical Components
In a non-limiting embodiment, the system comprises:
AE-501 — Agent Execution Environment
An artificial-intelligence agent, model runtime, autonomous workflow,
container, virtual machine, tool runtime, or associated computational
environment configured to generate proposed operations.
IB-502 — Interception and Request Broker
An enforcement-controlled component configured to receive proposed
operations from AE-501 and prevent unauthorized direct invocation of
effect-capable interfaces.
HQ-503 — Non-Effective Holding Mechanism
A queue, staged-request object, protected request record, immutable
operation buffer, or equivalent controlled mechanism retaining a
Candidate Act before effectuation.
DC-504 — Operation Descriptor Component
A mechanism configured to construct or verify a canonical Candidate
Act Descriptor.
PED-505 — Protected Enforcement Domain
A protected component configured to validate authority predicates,
maintain or verify protected state, commit required evidence, and
authorize availability of a scoped execution capability.
PS-506 — Protected Authorization-State Store
A component maintaining the applicable policy epoch, grant state,
revocation information, nonce state, operation-specific commitments,
usage state, and capability-consumption information.
EV-507 — Protected Validation-Evidence Component
A mechanism for generating or committing a LAVR, Egress LAVR, AVR,
sealed validation record, authenticated commitment, or other
protected authorization evidence.
Das Expires 19 April 2027 [Page 218]
Internet-Draft Protected AI Execution Finality October 2026
CR-508 — Scoped Capability Release Mechanism
A mechanism configured to generate, register, or release a scoped
non-bearer Execution-Enabling Capability.
AC-509 — Authenticated Inter-Component Communication Interface
A protected local or remote communication facility configured to
authenticate the communicating components and maintain the integrity
of exchanged authorization information.
PC-510 — Privileged Connector Execution Component
A component having controlled access to a service, protected
credential, host operation, database, API, network interface, or
other effect-capable resource that is not directly available to AE-
501.
IV-511 — Independent Execution Verifier
A mechanism associated with PC-510 or its effectuation interface,
configured to verify operation-specific authorization before
performing the governed operation.
CS-512 — Protected Credential or Resource Store
An optional HSM, secure enclave, protected secret store, resource-
control service, or equivalent protected component.
FS-513 — Connector Finality Sink
The technical boundary at which the connector's proposed operation
would become externally effective.
OS-514 — Protected Operation-Outcome Store
A protected mechanism maintaining completion, reservation, denial,
revocation, and indeterminate-effectuation information.
SC-515 — Cross-Component State-Consistency Mechanism
A protected mechanism configured to maintain or verify the required
correspondence of operation identity, authorization state, capability
scope, and finality conditions among participating components.
These components may be physically separated, colocated, or combined
within a protected node, provided the required protected authority
and effectuation-verification relationships remain satisfied.
Das Expires 19 April 2027 [Page 219]
Internet-Draft Protected AI Execution Finality October 2026
11.5.3. WF-05.3 — Establishment of the Agent-to-Connector Trust
Boundary
Before enabling governed agent operations, the system establishes a
trust boundary between AE-501 and PC-510.
The agent may prepare operations and submit requests, but does not
possess unrestricted authority to:
(a) invoke arbitrary privileged host operations;
(b) read or export protected connector credentials;
(c) modify the protected authorization state;
(d) replace protected capability-verification code;
(e) impersonate an authenticated connector;
(f) access unrestricted external service interfaces; or
(g) bypass an applicable Finality Sink.
In a host-based implementation, the agent and privileged connector
may execute as separate processes with distinct operating-system
identities, namespaces, security labels, service privileges, or
resource-access permissions.
In a virtual-machine implementation, the agent and connector may
operate in separate guest, host, enclave, or hypervisor-controlled
domains.
In a distributed implementation, the agent and connector may run on
separate computing nodes and communicate through authenticated
interfaces.
Physical separation is not required where an implementation provides
the protected logical boundaries necessary to enforce the specified
relationship.
11.5.4. WF-05.4 — Privileged Connector Security Configuration
PC-510 is configured with only the resource authority necessary for
its permitted connector functions.
A non-limiting connector configuration may define:
connector_id;
Das Expires 19 April 2027 [Page 220]
Internet-Draft Protected AI Execution Finality October 2026
connector_software_identity;
authorized_workload_classes;
permitted_service_identities;
permitted_operation_classes;
permitted_resource_scope;
credential_reference_allowlist;
network_destination_allowlist;
authorized_authority_issuer;
accepted_policy_epoch;
finality_sink_id;
required_verification_mode.
The connector does not automatically acquire unrestricted authority
over all resources available to its host.
Where a connector has access to several service credentials, its
protected credential-selection mechanism restricts which credential
may be applied to a particular authorized operation.
In a more restrictive implementation, different connector processes
are assigned different credentials, service destinations, or
execution privileges.
The system may prohibit an untrusted agent from creating a new
privileged connector or modifying the connector's permitted resource
scope without a separate protected authorization event.
11.5.5. WF-05.5 — Authentication of Inter-Component Communication
AC-509 establishes an authenticated communication relationship among
participating components.
For components on the same host, the communication facility may
employ an operating-system-controlled local socket, authenticated IPC
channel, protected shared-memory interface, secure enclave call, or
equivalent mechanism.
Das Expires 19 April 2027 [Page 221]
Internet-Draft Protected AI Execution Finality October 2026
Where operating-system peer credentials are used, the receiving
component obtains peer identity information from the trusted
operating-system communication interface rather than accepting a
caller-supplied identity string as authoritative.
For a Linux-based implementation, a local Unix-domain socket may
provide operating-system peer-credential information. The
implementation may additionally verify the associated service
identity, process lifetime, security label, cgroup identity, or
protected workload measurement where required.
For remotely separated components, the system may use mutually
authenticated TLS, authenticated service identities,
cryptographically authenticated messages, hardware-backed identities,
or an equivalent protected communication protocol.
A transport authentication mechanism proves only the properties
established by that mechanism. It does not independently establish
authorization for the requested consequential operation.
11.5.6. WF-05.6 — Connector Identity and Attestation
Each privileged connector may have a registered execution identity.
The identity may comprise:
(a) an authenticated operating-system service identity;
(b) a protected process identity;
(c) a workload identity;
(d) a signed software identity;
(e) a measured executable digest;
(f) a confidential-computing attestation measurement;
(g) a hardware-backed service identity; or
(h) an equivalent machine-verifiable connector identity.
Where hardware attestation is required, an attestation report may
identify a measured executable, protected workload configuration,
firmware version, security configuration, or other required measured
state.
An illustrative attestation verification condition is:
Das Expires 19 April 2027 [Page 222]
Internet-Draft Protected AI Execution Finality October 2026
AttestValid = SignatureValid AND MeasurementApproved AND
ChallengeFresh AND IdentityBound
where:
AttestValid denotes the result of connector-attestation verification;
SignatureValid verifies the authentication of the attestation
evidence and the applicable trust chain;
MeasurementApproved verifies the required software or workload
measurement;
ChallengeFresh verifies that the attestation evidence corresponds to
an acceptable freshness challenge or protected state;
IdentityBound verifies that the attested component is the connector
participating in the intended operation.
Attestation is mandatory only where required by the applicable
Authority Object or specified embodiment.
An authenticated identity alone does not authorize the connector to
perform every operation.
11.5.7. WF-05.7 — Candidate Connector Act Generation
AE-501 generates a proposed operation directed to a privileged
connector.
The proposed operation may comprise:
(a) invoking an enterprise application API;
(b) requesting an authenticated network transmission;
(c) updating a cloud resource;
(d) creating or modifying a database record;
(e) applying a protected signing credential;
(f) modifying a managed repository;
(g) dispatching an authorized notification;
(h) performing a payment or commerce operation;
Das Expires 19 April 2027 [Page 223]
Internet-Draft Protected AI Execution Finality October 2026
(i) invoking a host-side worker; or
(j) another effect-capable connector operation.
The proposed operation is classified as Candidate Connector Act CA-
516.
The classification identifies that the act, if completed, would
produce a governed consequential effect.
The agent's ability to generate CA-516 does not independently confer
the authority required for its completion.
11.5.8. WF-05.8 — Mandatory Interception and Non-Effective Staging
IB-502 receives or intercepts CA-516 before the privileged connector
completes the governed operation.
The operation is retained in HQ-503.
An illustrative staged operation record comprises:
operation_id;
agent_identity;
workload_identity;
requested_connector_id;
requested_operation;
target_service;
operation_parameters_reference;
credential_reference;
authority_reference;
policy_epoch;
status = NON_EFFECTIVE.
The privileged connector does not execute the operation merely
because the request is present in the queue.
Das Expires 19 April 2027 [Page 224]
Internet-Draft Protected AI Execution Finality October 2026
Where the operation contains mutable data, the broker creates a
controlled representation or immutable snapshot of effectuation-
relevant parameters.
The agent cannot modify the staged operation after authorization in a
manner that changes the consequential effect without causing a new
correspondence check or renewed authorization.
11.5.9. WF-05.9 — Construction of an Operation-Specific Canonical
Descriptor
DC-504 obtains the required Candidate Act attributes and constructs a
canonical descriptor.
A non-limiting descriptor comprises:
operation_id;
requesting_agent_identity;
workload_identity;
connector_identity;
executor_identity;
operation_class;
target_service_identity;
destination_or_resource;
request_parameters;
payload_digest;
credential_scope;
authorized_purpose;
authority_object_reference;
grant_state_version;
policy_epoch;
revocation_epoch;
Das Expires 19 April 2027 [Page 225]
Internet-Draft Protected AI Execution Finality October 2026
nonce;
expiry;
finality_sink_identity.
The descriptor may be produced using a deterministic serialization
procedure.
An illustrative expression is:
D = Canon_v(ACT, AGENT, EXEC, TARGET, PARAM, SCOPE, STATE, SINK)
where:
D denotes the canonical Candidate Act Descriptor;
Canon_v denotes deterministic canonicalization under encoding version
v;
ACT denotes the proposed operation;
AGENT denotes the authenticated requesting agent or workload
identity;
EXEC denotes the intended privileged executor identity;
TARGET denotes the destination, recipient, resource, or service;
PARAM denotes effectuation-relevant operation parameters;
SCOPE denotes the applicable execution and credential scope;
STATE denotes the required authorization-state version;
SINK denotes the designated Finality Sink identity.
Only fields required by the applicable authority and specified
embodiment must be included.
The descriptor is constructed so that materially different operations
cannot be treated as identical merely because their natural-language
descriptions are similar.
11.5.10. WF-05.10 — Cryptographic Authorization Commitment
In a cryptographic implementation, the protected system creates an
operation-specific commitment over the canonical descriptor.
Das Expires 19 April 2027 [Page 226]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative commitment is:
hD = H("DAS-CONNECTOR-v1" || Encode(D))
where:
hD denotes the operation-descriptor commitment;
H denotes a cryptographic hash function;
Encode denotes the specified deterministic byte encoding;
|| denotes concatenation of encoded values;
"DAS-CONNECTOR-v1" denotes an illustrative domain-separation label.
The commitment may be incorporated into a protected validation
receipt, authorization-state record, scoped execution capability, or
authenticated communication object.
The same canonicalization version and mandatory field interpretation
are used by the authorizing and verifying components.
Where an intermediate component is expressly permitted to transform a
request, the authorization identifies the permitted transformation
and preserves a verifiable relationship between the original and
transformed operation.
An unauthorized transformation causes the required descriptor
correspondence to fail.
11.5.11. WF-05.11 — Protected Authority Validation
PED-505 obtains the applicable Authority Object and protected
authorization state.
The Authority Object may identify:
(a) permitted requesting agents;
(b) permitted connector identities;
(c) approved operation classes;
(d) authorized services and resources;
(e) applicable credential scopes;
Das Expires 19 April 2027 [Page 227]
Internet-Draft Protected AI Execution Finality October 2026
(f) permitted operation parameters;
(g) required human approval;
(h) authorized purpose;
(i) applicable ALF, AIF, or RBD conditions;
(j) policy and revocation requirements;
(k) nonce, expiry, and usage restrictions; and
(l) designated Finality Sink identity.
The PED authenticates the Authority Object and evaluates its
mandatory predicates.
An illustrative validation expression is:
V = Pagent AND Pconnector AND Poperation AND Pscope AND Pstate
where:
V denotes the protected authorization result;
Pagent verifies the requesting agent or workload identity;
Pconnector verifies the permitted connector identity;
Poperation verifies the proposed operation and its effectuation-
relevant parameters;
Pscope verifies the permitted authority, credential, destination, and
resource scope;
Pstate verifies required freshness, policy, revocation, and usage
conditions.
Additional predicates are evaluated where required.
Failure of a mandatory condition prevents release of the
corresponding execution authority.
11.5.12. WF-05.12 — Protected Grant-State Validation and Consumption
PS-506 maintains or obtains the operation-specific authorization
state.
Das Expires 19 April 2027 [Page 228]
Internet-Draft Protected AI Execution Finality October 2026
Where an operation requires a single-use or bounded-use grant, the
PED verifies the applicable grant identifier, descriptor commitment,
authorized scope, validity interval, remaining usage count, and
current protected state.
Where required, a protected reservation or consumption transition is
performed before capability availability.
An illustrative transition is:
AVAILABLE → RESERVED(operation_id, state_version)
The transition is protected against unauthorized concurrent
consumption.
If the grant is already exhausted, reserved incompatibly, revoked, or
invalid, the required capability is withheld.
A connector cannot create a new protected grant merely by claiming
that an earlier permission existed.
11.5.13. WF-05.13 — Protected Validation-Evidence Commitment
Following successful validation, EV-507 generates or commits the
applicable protected validation evidence.
An illustrative protected record contains:
receipt_id;
operation_id;
canonical_descriptor_digest;
authority_object_reference;
validated_predicate_reference;
protected_grant_state;
authorized_connector_id;
policy_epoch;
revocation_state_reference;
finality_sink_id;
Das Expires 19 April 2027 [Page 229]
Internet-Draft Protected AI Execution Finality October 2026
protected_authentication.
The evidence may comprise a LAVR, Egress LAVR, AVR, sealed validation
record, authenticated commitment, or equivalent protected
representation.
Where the applicable claim requires protected evidence commitment
before or atomically with capability availability, the system
enforces that ordering.
A connector does not treat a conventional post-execution audit log as
a substitute for the required protected validation commitment.
11.5.14. WF-05.14 — Operation-Scoped Execution Capability
Upon successful completion of the applicable protected finality
transaction, CR-508 generates, registers, or makes available a scoped
execution capability.
An illustrative authenticated capability contains or securely
references:
capability_id;
operation_descriptor_digest;
authorization_receipt_digest;
authorized_agent_identity;
authorized_executor_identity;
authorized_connector_id;
authorized_resource;
permitted_operation;
credential_scope;
policy_epoch;
revocation_epoch;
grant_state_version;
nonce;
Das Expires 19 April 2027 [Page 230]
Internet-Draft Protected AI Execution Finality October 2026
expiry;
usage_limit;
finality_sink_id.
The capability may be implemented as a signed structure, MAC-
authenticated authorization object, protected table entry, sealed
handle, or equivalent protected enablement artifact.
Where a connector identity is mandatory, the capability is not usable
by a different executor solely because that executor possesses the
capability representation.
Where Finality Sink identity is mandatory, the capability does not
authorize another sink merely because the operation appears similar.
11.5.15. WF-05.15 — Protected Capability Delivery
PED-505 or CR-508 makes the execution capability available through
AC-509.
In a local implementation, the capability may be delivered through an
authenticated IPC message.
In a remote implementation, it may be transmitted through a mutually
authenticated channel or obtained from a protected capability-
verification service.
In a single-node implementation, the capability may be represented by
an internal protected authorization-table entry that PC-510
references.
The communication may include:
operation_id;
descriptor_digest;
capability_id;
capability_or_reference;
authorization_state_version;
receipt_commitment_reference;
intended_connector_id;
Das Expires 19 April 2027 [Page 231]
Internet-Draft Protected AI Execution Finality October 2026
intended_finality_sink_id.
The receiving component verifies that the message originates from an
authorized component.
The connector does not treat an unauthenticated agent-provided copy
of an apparent capability as sufficient execution authority.
11.5.16. WF-05.16 — Independent Executor Verification
Before performing the consequential operation, IV-511 independently
verifies the authorization.
The verification is performed at, or in mandatory control of, the
privileged execution interface.
The verifier obtains or reconstructs the actual operation descriptor
from the operation that PC-510 is prepared to perform.
The verifier evaluates:
(a) capability authenticity;
(b) authorized connector identity;
(c) authenticated requesting context;
(d) correspondence to the actual operation;
(e) permitted destination or resource;
(f) applicable credential scope;
(g) policy and revocation state;
(h) protected grant-state version;
(i) required freshness and nonce conditions;
(j) capability-consumption state;
(k) required validation-evidence commitment; and
(l) designated Finality Sink identity.
The verification does not rely solely upon a previous statement that
another component approved the operation.
Das Expires 19 April 2027 [Page 232]
Internet-Draft Protected AI Execution Finality October 2026
11.5.17. WF-05.17 — Independent Verification Predicate
An illustrative executor-side verification condition is:
PermitExecutor =
Auth(C)
AND Match(C,Dactual)
AND ExecutorBound(C,E)
AND GrantValid(C,G)
AND StateValid(C,S)
AND SinkBound(C,F)
where:
PermitExecutor denotes permission for the connector to perform the
governed operation;
C denotes the scoped execution capability;
Dactual denotes the descriptor reconstructed from the operation
actually presented;
E denotes the authenticated privileged executor identity;
G denotes the protected grant-state record;
S denotes the required current authorization state;
F denotes the designated Finality Sink;
Auth verifies capability authenticity;
Match verifies exact or expressly permitted bounded correspondence
with the actual operation;
ExecutorBound verifies the permitted executor identity or
attestation;
GrantValid verifies the required grant reservation, version, and
usage conditions;
Das Expires 19 April 2027 [Page 233]
Internet-Draft Protected AI Execution Finality October 2026
StateValid verifies the mandatory policy, revocation, freshness, and
protected-state conditions;
SinkBound verifies the permitted effectuation boundary.
The connector proceeds only if PermitExecutor is true.
Where one protected component performs both authorization and local
effectuation, the required verification may be implemented as a
distinct protected verification operation within that component.
Independent verification describes the required enforcement function
and does not necessarily require a separate physical computer.
11.5.18. WF-05.18 — Cross-Component Authorization Consistency
Where multiple components participate in one governed operation, the
system ensures that each participating enforcement component verifies
the authorization attributes required for its role.
For example, the PED, credential broker, privileged connector,
network gateway, and receiving-side Finality Sink may each require
correspondence to the same underlying Candidate Act.
A representative common authorization commitment comprises:
operation_id;
canonical_descriptor_digest;
authority_object_reference;
authorization_state_version;
policy_epoch;
revocation_epoch;
permitted_operation_scope;
authorized_finality_boundary;
protected_validation_receipt_reference.
Each component validates the common commitment and any additional
component-specific restrictions.
Das Expires 19 April 2027 [Page 234]
Internet-Draft Protected AI Execution Finality October 2026
Where different components use separate capability artifacts, those
artifacts are cryptographically or otherwise protectedly bound to the
same underlying authorized operation and to their respective
permitted execution boundaries.
The system does not infer authorization for one component solely from
another component's successful verification.
11.5.19. WF-05.19 — Mathematical Cross-Component Consistency Condition
Let:
D denote the authorized canonical Candidate Act Descriptor;
hD denote its authenticated commitment;
Cj denote the execution-enablement artifact verified by component j;
Ej denote the authenticated execution identity of component j;
Fj denote the effectuation boundary governed by component j;
Sj denote the protected authorization state required by component j;
j denote a component index from 1 through m;
m denote the number of participating enforcement components.
For a component requiring the common descriptor commitment, the local
consistency condition may be represented as:
Consistent(j) =
Auth(Cj)
AND DescriptorBound(Cj,hD)
AND ComponentBound(Cj,Ej)
AND BoundaryBound(Cj,Fj)
AND StateValid(Cj,Sj)
where:
Auth verifies the authenticity of the component's authorization
artifact;
Das Expires 19 April 2027 [Page 235]
Internet-Draft Protected AI Execution Finality October 2026
DescriptorBound verifies correspondence to the common authorized
operation;
ComponentBound verifies the authorized execution component;
BoundaryBound verifies the component's permitted effectuation
boundary;
StateValid verifies the required protected authorization state.
For an operation requiring verification by all designated components:
PermitFinal = Consistent(1) AND Consistent(2) AND ... AND
Consistent(m)
This mathematical expression models a conjunctive multi-component
authorization arrangement.
Where components verify distinct stages or operations, the applicable
authorization dependencies are specified for those stages rather than
assuming that every component verifies every unrelated operation.
The existence of a common descriptor commitment does not itself
establish distributed-state consistency. The implementation also
enforces the required state-version, revocation, freshness, and
consumption conditions.
11.5.20. WF-05.20 — Protection Against Cross-Component State Drift
Authorization state may change while an operation progresses among
components.
Examples include:
(a) policy revision;
(b) revocation of agent authority;
(c) connector identity change;
(d) credential revocation;
(e) grant consumption;
(f) destination substitution;
(g) workload replacement;
Das Expires 19 April 2027 [Page 236]
Internet-Draft Protected AI Execution Finality October 2026
(h) expiration of an execution capability; or
(i) change in required Finality Sink identity.
To prevent authorization under incompatible state, each applicable
Finality Sink verifies its required current state or an acceptable
protected state commitment immediately before effectuation.
For a strict revocation guarantee, the enforcement arrangement may
require an online protected-state check, an authenticated revocation
fence, or another mechanism that prevents acceptance of a capability
after the relevant invalidating transition.
Where bounded-staleness authorization is expressly permitted, the
system enforces the specified validity interval and freshness limits.
If required state cannot be obtained or verified, the affected
operation is withheld.
The system does not assume that eventually consistent caches provide
instantaneous revocation across all nodes.
11.5.21. WF-05.21 — Authorization Epoch and Revocation Fence
In one implementation, the protected authorization state includes an
execution or policy epoch.
A capability is bound to the epoch that formed part of its required
authorization.
A protected policy or revocation change advances the relevant epoch
or another authenticated state-generation value.
Before effectuation, the Finality Sink compares the capability-bound
epoch with the epoch permitted by current protected state.
An illustrative condition is:
EpochValid = AcceptedEpoch(C.epoch, CurrentState)
where:
EpochValid denotes whether the capability's bound epoch remains
acceptable;
C.epoch denotes the epoch referenced by the capability;
Das Expires 19 April 2027 [Page 237]
Internet-Draft Protected AI Execution Finality October 2026
CurrentState denotes the protected policy and revocation state
consulted by the verifier;
AcceptedEpoch denotes the protected rule determining whether the
bound epoch is currently valid.
The rule need not require literal equality where an embodiment
expressly permits an authorized transition window.
For immediate invalidation requirements, the relevant sink must
receive or verify the revocation fence before allowing another
affected operation.
A component unable to establish the required state does not treat a
stale cached allow decision as sufficient.
11.5.22. WF-05.22 — Protection Against the Confused-Deputy Condition
A privileged connector may have greater resource access than the
agent that requests its services.
An unauthorized agent could attempt to exploit this difference by
persuading the connector to use its privileged authority for an
operation outside the agent's permitted scope.
The protected execution-finality mechanism prevents such authority
substitution by requiring the connector to verify:
(a) who requested the operation;
(b) which operation was actually authorized;
(c) which resources and credentials are permitted;
(d) which protected grant authorizes the effect;
(e) whether the grant remains valid; and
(f) whether the actual effectuation boundary corresponds to the
authorization.
For example, an agent permitted to read a document through a
restricted connector cannot use that connector's broader host
privileges to modify unrelated enterprise records merely by
constructing a different API request.
The connector verifies operation-specific authority rather than
relying solely upon its own service-account privileges.
Das Expires 19 April 2027 [Page 238]
Internet-Draft Protected AI Execution Finality October 2026
11.5.23. WF-05.23 — Credential and Resource Isolation
Where PC-510 requires a credential, the credential may be maintained
within CS-512 or a separately protected credential service.
The connector obtains or uses the credential only in accordance with
the applicable scoped authorization.
The agent may possess a credential reference but cannot independently
retrieve or apply unrestricted reusable credential material.
In a non-exportable key embodiment, CS-512 performs a protected
cryptographic operation after the required authorization conditions
have been established.
In an API-token embodiment, PC-510 applies a protected token to the
validated service request through its controlled effectuation
interface.
Where a credential can be used against multiple services or tenants,
the connector enforces the narrower operation-specific scope required
by the corresponding capability.
Detailed credential substitution and protected grant-state
consumption are described in WF-04.
11.5.24. WF-05.24 — Final Operation Binding and Mutation Prevention
The protected architecture verifies that the operation presented by
PC-510 immediately before effectuation remains consistent with the
authorized operation.
For an API request, the connector may retain an immutable operation
object comprising the selected destination, resource, method,
permitted headers, body digest, authenticated tenant context, and
credential scope.
The connector derives its actual-operation descriptor from that
controlled object.
If a request transformation is required, such as inserting a
protected credential, the implementation defines the permitted
transformation and verifies that no unauthorized effectuation-
relevant field has changed.
If a request is modified after authorization in a manner outside the
permitted scope, the capability cannot authorize the changed request.
Das Expires 19 April 2027 [Page 239]
Internet-Draft Protected AI Execution Finality October 2026
The system may employ protected immutable buffers, authenticated
message objects, locked operation descriptors, controlled request
construction, or other mechanisms appropriate to the execution
environment.
11.5.25. WF-05.25 — Multiple Effectuation Boundaries
A connector-mediated workflow may involve several consequential
boundaries.
For example:
(a) the credential broker may authorize use of a protected signing
key;
(b) the connector may prepare an authenticated external request;
(c) the network gateway may control actual transmission; and
(d) a receiving service may control final database commitment.
Each boundary may require its own capability or an expressly bounded
authorization artifact that independently verifies against the
relevant operation and sink.
In a single-sink embodiment, one enforcement-controlled connector may
perform the complete governed effectuation sequence.
In a multi-sink embodiment, authorization to sign a request does not
automatically authorize transmission through a different network
boundary.
Likewise, authorization to transmit does not independently authorize
a receiving system to commit an unrelated or materially different
operation.
The system identifies the effectuation boundary actually controlled
by each Finality Sink.
11.5.26. WF-05.26 — Illustrative End-to-End Privileged Connector
Implementation
In one concrete embodiment, an enterprise AI agent proposes creation
of a customer-support record through a protected cloud application
connector.
The agent executes in an isolated container without direct access to
the enterprise service's reusable API credential.
Das Expires 19 April 2027 [Page 240]
Internet-Draft Protected AI Execution Finality October 2026
The agent prepares an operation identifying the intended service,
authorized tenant, customer reference, record type, request
parameters, and permitted operation class.
The operation is submitted to IB-502 and retained as CA-516 in a Non-
Effective State.
DC-504 constructs the canonical operation descriptor and binds the
requesting workload, designated connector, target service, request
parameters, authorization-state version, and Finality Sink identity.
PED-505 obtains the applicable Authority Object.
The protected validation verifies that:
(a) the agent is permitted to request the operation;
(b) the connector is approved for the target service;
(c) the requested record type and resource scope are authorized;
(d) the operation remains within its permitted purpose;
(e) the protected policy and revocation conditions are valid;
(f) the required credential scope is permitted; and
(g) the protected grant remains available for the operation.
PS-506 performs the required protected grant-state operation.
EV-507 commits a validation record binding the canonical descriptor,
grant state, and authorized connector.
CR-508 releases an operation-specific capability bound to the
protected commitment, executor identity, target service,
authorization state, and designated Finality Sink.
PC-510 receives the staged operation through an authenticated inter-
component interface.
The connector authenticates its own service identity or presents the
required attestation evidence to the relevant verifier.
IV-511 reconstructs the actual operation descriptor and verifies the
capability against the current required protected state.
Das Expires 19 April 2027 [Page 241]
Internet-Draft Protected AI Execution Finality October 2026
Upon successful verification, the connector obtains or applies the
protected service credential through CS-512.
The connector prepares the authorized external API request without
exposing reusable credential material to the AI agent.
FS-513 independently verifies the required execution capability
before the corresponding governed external service invocation.
If the agent substitutes a different customer, operation type, target
service, credential scope, or unauthorized request parameter, the
required descriptor correspondence fails.
If the connector's registered identity has changed incompatibly or
its protected authorization state has been revoked, the operation is
withheld.
After the governed effectuation attempt, OS-514 records the
appropriate confirmed, denied, or indeterminate outcome.
The connector does not treat successful host authentication or
possession of the service credential as authority to perform
unrelated operations.
11.5.27. WF-05.27 — Alternative Host and Distributed Implementations
Single-host implementation: The agent and connector execute as
isolated processes. An authenticated local IPC interface transfers
operation references and authorization artifacts. A protected host
broker enforces the required Finality Sink checks.
Hypervisor implementation: The agent executes within a guest VM,
while the privileged connector resides in a protected host or service
domain. A virtual-device or authenticated inter-domain interface
mediates requests.
Confidential-computing implementation: The connector or governance
service operates within an attested confidential workload. The
required attestation state is bound to the protected authorization
conditions.
Distributed implementation: The PED, connector, and effectuation
gateway reside on separate nodes and communicate over authenticated
channels. Each relevant effectuation component verifies the
operation-specific commitment and required state.
Das Expires 19 April 2027 [Page 242]
Internet-Draft Protected AI Execution Finality October 2026
Service-mesh implementation: A workload proxy, sidecar, ingress
controller, or egress gateway performs the applicable finality
verification for service-to-service operations.
Hardware-assisted implementation: A SmartNIC, DPU, protected network
gateway, or other hardware-controlled interface verifies the required
capability before enabling the governed output.
Protected signing implementation: An HSM or secure enclave performs
the authorized cryptographic operation without exporting the
protected private key.
Receiving-side implementation: A trusted receiving service
independently verifies the operation-specific capability before
applying the governed database, service, payment, or other
consequential operation.
These alternatives have different trust assumptions and enforcement
strengths. They do not automatically provide equivalent resistance
to privileged compromise, rollback, remote-node failure, or hardware
attacks.
11.5.28. WF-05.28 — Failure, Timeout, and Recovery Handling
The protected system operates fail-closed for mandatory authorization
and verification conditions.
A proposed connector operation is withheld when:
(a) the connector identity cannot be authenticated;
(b) mandatory attestation fails;
(c) the requesting workload is unauthorized;
(d) the actual operation differs from the validated operation;
(e) the protected capability is missing or invalid;
(f) the required grant-state version is inconsistent;
(g) the capability has expired or been consumed;
(h) required revocation state is unavailable or invalid;
(i) the target service is unauthorized;
(j) the required credential scope is invalid;
Das Expires 19 April 2027 [Page 243]
Internet-Draft Protected AI Execution Finality October 2026
(k) a participating component presents an incompatible authorization
commitment;
(l) a required receipt commitment cannot be verified; or
(m) the corresponding Finality Sink verification fails.
If a connector crashes before effectuation, the system consults the
protected operation and capability state before authorizing further
activity.
If the connector crashes after possible external effectuation, the
system distinguishes confirmed completion from indeterminate
completion.
An uncertain operation is not automatically replayed when doing so
could cause an unauthorized duplicate effect.
An authenticated receiving-side receipt, external idempotency
mechanism, transaction-status query, or protected recovery procedure
may assist with reconciliation.
The workflow does not assume that arbitrary external services support
globally atomic transactions or unconditional exactly-once execution.
11.5.29. WF-05.29 — PHOSITA Verification and Negative Tests
A person having ordinary skill in operating-system security,
distributed systems, protected credential management, authenticated
IPC, API gateways, or cloud-native infrastructure may verify the
embodiment through the following tests.
Test 1 — Authorized connector operation: A valid agent request,
connector identity, grant state, and scoped capability permit the
authorized operation.
Test 2 — Missing capability: A connector request lacking the required
capability is refused.
Test 3 — Unauthorized executor: A different process or service
attempts to use a capability bound to another executor. Verification
fails where executor binding is required.
Test 4 — Identity spoofing: An untrusted caller supplies an approved
connector name without authenticated identity evidence. The request
is refused.
Das Expires 19 April 2027 [Page 244]
Internet-Draft Protected AI Execution Finality October 2026
Test 5 — Stale attestation: A connector presents an outdated or
invalid required attestation. The attestation predicate fails.
Test 6 — Operation substitution: The request body or effectuation-
relevant resource changes after authorization. Descriptor
verification fails.
Test 7 — Credential-scope misuse: A connector attempts to apply a
protected credential outside the authorized resource or service
scope. Credential effectuation is refused.
Test 8 — Cross-tenant substitution: A request is redirected to
another tenant when tenant identity is mandatory. The authorization
binding fails.
Test 9 — Concurrent grant consumption: Two incompatible operations
attempt to consume one single-use grant. The protected state
mechanism prevents unauthorized double consumption.
Test 10 — Cross-component epoch mismatch: A Finality Sink receives a
capability bound to an incompatible policy or revocation epoch.
Verification fails.
Test 11 — Component restart: A privileged connector restarts with a
changed required execution identity or measurement. Previously bound
capabilities are rejected unless the protected authorization permits
the new context.
Test 12 — Lost protected-state service: The connector cannot
establish a mandatory current protected-state condition. The
operation remains non-effective.
Test 13 — Unauthorized alternate route: The agent attempts to invoke
the protected resource without passing through the governed connector
or Finality Sink. The attempted bypass is prevented through the
selected enforcement mechanism.
Test 14 — Capability replay: A previously consumed operation-specific
capability is presented again. The protected consumption condition
refuses unauthorized reuse.
Test 15 — Partial external completion: A connector crashes after
possible request delivery. The operation is placed into an
appropriate protected completion or recovery state instead of
automatically generating an unrestricted duplicate attempt.
Das Expires 19 April 2027 [Page 245]
Internet-Draft Protected AI Execution Finality October 2026
Test 16 — Multi-sink verification: A capability restricted to one
Finality Sink is presented at another governed boundary. It is
rejected unless the applicable authorization expressly permits that
boundary.
Test 17 — Inconsistent authorization commitments: Two participating
protected components receive commitments representing different
required Candidate Act parameters. The final consequential operation
remains withheld until consistency is restored through an authorized
procedure.
Test 18 — Revocation during a distributed operation: A protected
revocation transition invalidates an outstanding capability. A
Finality Sink requiring current revocation information refuses
further effectuation under the invalidated state.
Such tests may be performed using isolated agent processes, mock
connectors, protected authorization services, authenticated IPC
endpoints, simulated policy changes, test credentials, and controlled
external-service interfaces.
11.5.30. WF-05.30 — Technical Effect
The embodiment establishes a protected technical dependency between:
(a) agent generation of a proposed connector operation;
(b) mandatory interception;
(c) Non-Effective State staging;
(d) canonical Candidate Act Descriptor binding;
(e) protected authority-predicate validation;
(f) protected grant-state handling;
(g) required validation-evidence commitment;
(h) scoped non-bearer capability availability;
(i) authenticated connector identity or attestation where required;
(j) independent executor-side operation verification;
(k) cross-component authorization consistency;
(l) controlled credential or resource use;
Das Expires 19 April 2027 [Page 246]
Internet-Draft Protected AI Execution Finality October 2026
(m) Finality Sink verification; and
(n) permitted effectuation or fail-closed refusal.
The system prevents the authority held by a privileged connector from
becoming unrestricted authority delegated to the artificial-
intelligence agent.
The system further prevents participating components from authorizing
and effectuating materially different operations through inconsistent
descriptors, incompatible authorization-state versions, stale grants,
or improperly transferred capabilities.
The essential protected dependency may be implemented through
software isolation, firmware, cryptographic protection, hardware-
rooted enforcement, or distributed protected components, subject to
the guarantees required by the particular embodiment.
Computation is not authority to act.
Connector privilege is not transferable execution authority.
A component's earlier approval is not a substitute for verification
of the actual consequential operation at its applicable Finality
Sink.
11.6. WF-06 — Untrusted-Input Provenance, Process-Lineage Influence
Propagation, Taint-State Authorization Degradation, and Protected
Egress Finality
11.6.1. WF-06.1 — Technical Purpose
This embodiment provides a computer-implemented protected execution-
finality system configured to prevent untrusted information
encountered by an artificial-intelligence agent, application, tool,
process, subprocess, or session from being promoted into unauthorized
execution authority.
The system maintains machine-verifiable provenance and influence
information identifying the origin, trust classification, and
permitted use of data or instructions encountered during execution.
In certain embodiments, influence state is maintained at a context-
unit or Candidate Act level. In further embodiments, the influence
state is associated with an execution process, subprocess, thread
group, agent session, workload, or execution lineage and propagated
to subsequent execution contexts according to protected propagation
rules.
Das Expires 19 April 2027 [Page 247]
Internet-Draft Protected AI Execution Finality October 2026
The propagated state influences the authorization conditions
applicable to subsequent Candidate Acts.
An operation previously eligible for a broader execution scope may
become subject to narrower permissions, additional protected
validation requirements, or denial following a defined interaction
with untrusted information.
The resulting system prevents an agent or its descendant execution
contexts from obtaining execution authority inconsistent with a
required protected influence state.
The system distinguishes observation of untrusted information from
authorization to obey instructions contained in that information.
Untrusted material may be used as evidence, task data, or bounded
computational input where permitted, but cannot independently
override higher-trust instructions, modify protected authority, or
authorize a consequential operation.
11.6.2. WF-06.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises:
AE-601 — Agent Execution Environment
An artificial-intelligence agent, model runtime, tool-execution
environment, process, container, virtual machine, or autonomous
workflow configured to receive and process information.
IS-602 — Input and Source Classification Component
A component configured to classify incoming data according to its
authenticated source, provenance, trust tier, content class, and
applicable instruction-authority restrictions.
CB-603 — Connector Boundary Component
A protected or enforcement-controlled retrieval, tool-response,
application, or data-ingestion interface configured to record
relevant source and retrieval-boundary information.
IT-604 — Instruction Taint Boundary Object Manager
A protected mechanism configured to construct, store, or verify an
Instruction Taint Boundary Object (ITBO), including applicable
instruction hierarchy, context trust classifications, taint rules,
and trust-elevation conditions.
Das Expires 19 April 2027 [Page 248]
Internet-Draft Protected AI Execution Finality October 2026
LM-605 — Protected Lineage-State Manager
A component configured to maintain or verify the influence state
associated with a process, subprocess, session, agent runtime, or
corresponding execution lineage.
EM-606 — Execution-Event Monitor
A mechanism configured to observe or mediate defined execution
events, including data ingestion, process creation, session
continuation, tool dispatch, IPC, or other events relevant to the
protected influence-state rules.
PS-607 — Protected State Store
A protected or enforcement-controlled state mechanism maintaining
lineage identities, influence records, authorization-state versions,
policy epochs, and relevant receipt commitments.
DC-608 — Candidate Act Descriptor Component
A component configured to construct a Candidate Act Descriptor
containing or referencing required provenance and influence
information.
PED-609 — Protected Enforcement Domain
A protected authorization component configured to evaluate applicable
Authority Objects, ITBO conditions, influence-state predicates,
execution scope, and current protected authorization state.
EV-610 — Protected Evidence Component
A mechanism configured to generate or commit protected validation
evidence, including an applicable LAVR, Egress LAVR, or authenticated
validation commitment.
CR-611 — Capability Release Component
A protected mechanism configured to release or make available a
scoped non-bearer execution capability following satisfaction of the
required predicates.
FS-612 — Finality Sink
An enforcement-controlled interface configured to verify the required
execution capability and applicable influence-state binding before
allowing the consequential operation.
Das Expires 19 April 2027 [Page 249]
Internet-Draft Protected AI Execution Finality October 2026
RC-613 — Protected Recovery and Revalidation Component
An optional mechanism configured to manage authorized state reset,
fresh execution contexts, trust elevation, revocation, and recovery.
The components may be colocated or distributed, provided that the
required protected state and effectuation dependencies are
maintained.
11.6.3. WF-06.3 — Instruction Trust Hierarchy
The system establishes an applicable instruction trust hierarchy.
In an embodiment using an ITBO, the hierarchy may distinguish:
(a) constitutional or root authority conditions, where present;
(b) provider or model-safety instructions;
(c) operator, enterprise, or developer instructions;
(d) authorized user instructions;
(e) authorized tool outputs having bounded operational meaning; and
(f) retrieved evidence, webpages, files, emails, external messages,
document content, and other lower-trust information.
The specific hierarchy may differ according to the application and
Authority Object.
A lower-trust content unit does not independently modify or supersede
a higher-trust authority condition.
For example, text retrieved from a webpage may provide factual
information relevant to a user's task, but a command embedded in that
webpage cannot independently expand the agent's tool permissions or
authorize transmission of protected information.
The ITBO identifies which content sources may provide evidence, which
may supply bounded parameters, and which, if any, may exercise
instruction authority under an expressly authorized trust-elevation
condition.
11.6.4. WF-06.4 — Source and Context-Unit Identification
Incoming information may comprise:
Das Expires 19 April 2027 [Page 250]
Internet-Draft Protected AI Execution Finality October 2026
(a) user instructions;
(b) webpages;
(c) retrieved documents;
(d) email messages;
(e) tool responses;
(f) API responses;
(g) package metadata;
(h) source-code comments;
(i) repository files;
(j) vector-database records;
(k) model-generated outputs;
(l) browser document-object-model content;
(m) clipboard content;
(n) OCR or extracted document text;
(o) memory records; or
(p) another agent's message.
Each relevant input is associated with a source reference or context-
unit identifier.
An illustrative context-unit record comprises:
context_unit_id;
source_identity;
source_type;
content_digest;
retrieval_event_id;
connector_identity;
Das Expires 19 April 2027 [Page 251]
Internet-Draft Protected AI Execution Finality October 2026
trust_tier;
taint_classification;
instruction_authority_flag;
evidence_only_flag;
tool_control_restriction;
memory_write_restriction;
permitted_data_scope;
policy_epoch;
freshness_reference.
The record may identify the original content by digest or protected
reference rather than retaining complete plaintext.
A source-provided declaration of trust is not treated as
independently authoritative unless the applicable authentication
conditions have been satisfied.
11.6.5. WF-06.5 — Connector Boundary Receipt
Where information is obtained through a governed retrieval or
connector boundary, CB-603 may generate or obtain a Connector
Boundary Receipt (CBR).
The CBR associates retrieved information with the relevant retrieval
request, source identity, admitted or excluded content, authorized
retrieval scope, and applicable provenance or taint conditions.
An illustrative CBR record may contain:
cbr_id;
retrieval_operation_id;
connector_identity;
source_reference;
retrieved_object_digest;
source_class;
Das Expires 19 April 2027 [Page 252]
Internet-Draft Protected AI Execution Finality October 2026
trust_tier;
admission_result;
taint_classification;
permitted_use_scope;
policy_epoch;
protected_authentication.
The CBR establishes evidence concerning the governed retrieval
boundary.
It does not, by itself, authorize instructions contained within the
retrieved material to modify protected authority.
For example, the retrieval of a webpage may be authorized, while
execution of a shell command appearing in that webpage remains
unauthorized.
11.6.6. WF-06.6 — Construction of the Instruction Taint Boundary Object
IT-604 constructs or verifies the ITBO applicable to the agent
session or execution context.
A representative ITBO includes or securely references:
instruction_hierarchy_digest;
higher_authority_digest;
approved_user_instruction_scope;
context_trust_map;
evidence_content_root;
connector_receipt_references;
trust_elevation_rules;
taint_propagation_rules;
prohibited_instruction_promotions;
injection_classification_state;
Das Expires 19 April 2027 [Page 253]
Internet-Draft Protected AI Execution Finality October 2026
policy_epoch;
revocation_epoch;
nonce;
protected_authentication.
The ITBO is maintained under control of the applicable PED or other
protected authority.
An agent cannot create instruction authority merely by rewriting a
context label, fabricating a source identity, or declaring an
external document to be trusted.
Where cryptographically protected, the ITBO may comprise a signed
object, authenticated commitment, protected record, Merkle-rooted
trust map, or equivalent representation.
The specific cryptographic encoding depends upon the selected
implementation.
11.6.7. WF-06.7 — Influence-State Representation
in an implementation supporting enforcement point 25, LM-605
maintains a protected influence state associated with an execution
context.
Let:
p denote an identified process, subprocess, agent session, or other
monitored execution context;
t denote a logical event or state version;
L(p,t) denote the protected influence state associated with p at
version t.
The influence state may be represented as a set of influence labels
rather than a single Boolean taint bit.
Illustrative labels include:
UNTRUSTED_WEB_CONTENT;
UNTRUSTED_EMAIL_CONTENT;
EXTERNAL_TOOL_RESPONSE;
Das Expires 19 April 2027 [Page 254]
Internet-Draft Protected AI Execution Finality October 2026
UNVERIFIED_INSTRUCTION_ATTEMPT;
SENSITIVE_DATA_EXPOSURE;
UNTRUSTED_CODE_INPUT;
UNKNOWN_PROVENANCE;
TRUST_ELEVATION_PENDING.
The labels describe source influence and applicable restrictions.
Their presence does not necessarily establish that malicious behavior
has occurred.
An illustrative protected lineage record comprises:
lineage_identity;
parent_lineage_identity;
workload_identity;
execution_identity;
process_generation;
session_identity;
influence_labels;
source_receipt_references;
state_version;
policy_epoch;
last_protected_event;
protected_authentication.
The influence-state record is maintained outside direct modification
authority controlled by the untrusted agent.
11.6.8. WF-06.8 — Secure Execution-Lineage Identity
The system identifies the process or session to which an influence
state belongs.
Das Expires 19 April 2027 [Page 255]
Internet-Draft Protected AI Execution Finality October 2026
In a process-based implementation, a lineage identity may be derived
from a combination of:
(a) process identifier;
(b) process-namespace identity;
(c) process creation generation or start reference;
(d) authenticated parent identity;
(e) container or workload identity;
(f) executable identity;
(g) execution-session identifier; and
(h) an authenticated event reference.
The system does not rely solely upon an operating-system process
identifier where that identifier can be reused after a process
terminates.
A logical lineage identifier may be assigned at process creation and
retained across authorized execution-state transitions.
Where multiple threads share a common process address space or
relevant agent context, the embodiment may maintain a shared
influence state for the thread group.
The particular lineage granularity is selected according to the
execution and threat model.
11.6.9. WF-06.9 — Initial Influence-State Assignment
When a new execution context is established, LM-605 assigns an
initial protected influence state.
The initial state may depend upon:
(a) the authenticated workload identity;
(b) the creating execution context;
(c) inherited influence state;
(d) initial process inputs;
Das Expires 19 April 2027 [Page 256]
Internet-Draft Protected AI Execution Finality October 2026
(e) restored session or memory state;
(f) approved workflow configuration; and
(g) the applicable protected policy.
A newly created process is not automatically treated as free from
untrusted influence merely because it has a new process identifier.
A genuinely fresh execution context having no inherited untrusted
inputs may receive a policy-defined baseline state.
A child process created from an influenced parent receives the state
required by the protected propagation rules.
A restored workload receives an influence state consistent with its
protected session and recovery information.
11.6.10. WF-06.10 — Defined Untrusted-Information Interaction Events
EM-606 identifies events that may modify an execution context's
protected influence state.
A defined interaction event may comprise:
(a) receiving an external tool result;
(b) reading retrieved webpage content;
(c) ingesting an email or document;
(d) incorporating a retrieved chunk into an AI model context;
(e) parsing an untrusted configuration or package manifest;
(f) receiving an IPC message containing lower-trust material;
(g) loading untrusted code or a script;
(h) importing untrusted memory content;
(i) receiving an agent message having an applicable lower-trust
classification; or
(j) another policy-defined information-consumption event.
A mere attempted read need not be treated identically to successful
ingestion unless the applicable policy requires that treatment.
Das Expires 19 April 2027 [Page 257]
Internet-Draft Protected AI Execution Finality October 2026
The event monitor distinguishes, where technically possible, data
discovery, attempted access, successful receipt, actual consumption,
and subsequent use.
Where the implementation cannot reliably determine actual semantic
influence, the policy may conservatively classify receipt or
availability within an execution context as sufficient to trigger the
corresponding influence state.
The selected rule is specified by the implementation rather than
presumed.
11.6.11. WF-06.11 — Protected Influence-State Update
When a defined interaction event occurs, LM-605 updates the protected
influence state.
Let:
L(p,t) denote the influence-label set for execution context p before
event t;
e denote the observed or mediated event;
Labels(e) denote the influence labels assigned to event e;
U denote the protected update function.
The next influence state may be expressed as:
L(p,t+1) = U(L(p,t), Labels(e))
In a conservative accumulating-label implementation:
L(p,t+1) = L(p,t) ∪ Labels(e)
where:
∪ denotes set union.
The operation preserves existing applicable influence labels and adds
labels associated with the newly observed event.
For example, a process that has incorporated untrusted webpage
content may acquire the UNTRUSTED_WEB_CONTENT label.
A later read of an untrusted email may additionally add
UNTRUSTED_EMAIL_CONTENT.
Das Expires 19 April 2027 [Page 258]
Internet-Draft Protected AI Execution Finality October 2026
The label update does not itself authorize or deny every possible
operation.
Instead, the resulting protected influence state becomes an input to
applicable authorization predicates.
11.6.12. WF-06.12 — Process Creation and Descendant Propagation
In an embodiment supporting process-lineage influence propagation,
EM-606 monitors or mediates a defined process-creation event.
Such events may comprise process fork, supported clone operations,
subprocess creation, worker creation, agent-worker spawning,
container-child creation, or equivalent execution branching.
When a child execution context is created, LM-605 establishes a
protected lineage record associating the child with its parent.
Let:
p denote a parent execution context;
q denote a newly created child execution context;
L(p,t) denote the parent's protected influence state;
Lspawn denote any additional influence labels applicable to the
creation event;
L(q,t+1) denote the child's initial protected influence state.
A non-limiting inheritance rule is:
L(q,t+1) = L(p,t) ∪ Lspawn
Under this rule, the child inherits the influence restrictions
applicable to the parent at the protected creation boundary.
The creation of a child process does not automatically restore a
broader authorization scope that was unavailable to the parent.
If a higher-assurance implementation requires particular source
categories, credentials, session data, or shared-memory inputs to
remain associated with the child, those bindings are included in the
protected lineage record.
Das Expires 19 April 2027 [Page 259]
Internet-Draft Protected AI Execution Finality October 2026
11.6.13. WF-06.13 — Process Execution and Image Replacement
Some operating systems permit a process to replace its executable
image while retaining a process identity or selected resources.
In such an embodiment, an executable-image replacement does not
automatically erase protected influence state.
A new executable identity may be measured or authenticated, but the
existing lineage influence state remains applicable unless a
protected reset or state-transition rule authorizes a different
result.
For example, an agent runtime that has incorporated untrusted webpage
instructions cannot restore a broader execution authorization simply
by launching a shell or replacing its own executable image.
Where an execution transition deliberately creates a new isolated
context with no inherited untrusted state, the applicable protected
authority validates that isolation and state reset before assigning
the new baseline.
11.6.14. WF-06.14 — Session, Agent, and Worker-Lineage Propagation
The influence-state mechanism is not limited to conventional
operating-system processes.
In an AI agent implementation, the relevant execution context may
comprise:
(a) an agent session;
(b) a tool-execution session;
(c) an agent worker;
(d) a subordinate agent;
(e) a model-context instance;
(f) a workflow branch;
(g) a serverless invocation;
(h) a browser automation context; or
(i) another logical execution unit.
Das Expires 19 April 2027 [Page 260]
Internet-Draft Protected AI Execution Finality October 2026
Where a workflow spawns another agent or worker and transfers
influenced context, the protected system associates the receiving
execution context with the applicable source lineage.
A newly created subordinate agent does not become authorized to
disregard a required influence restriction merely because it executes
in another process or container.
Delegated execution authority remains subject to the scope
restrictions of the corresponding Delegation Authority Object and the
relevant downstream Candidate Act authorization.
11.6.15. WF-06.15 — IPC, Shared Memory, and Cross-Process Information
Transfer
The implementation may propagate influence state when information is
transferred between execution contexts.
Relevant mechanisms include:
(a) authenticated IPC messages;
(b) operating-system pipes;
(c) local socket communication;
(d) shared-memory regions;
(e) file-descriptor transfer;
(f) controlled file reads;
(g) message queues;
(h) tool-response channels;
(i) connector responses; and
(j) equivalent data-transfer mechanisms.
Where a receiving process ingests information carrying an applicable
influence label, LM-605 updates the receiver's protected influence
state according to the selected propagation rule.
A data-transfer record may identify:
source_lineage_id;
Das Expires 19 April 2027 [Page 261]
Internet-Draft Protected AI Execution Finality October 2026
destination_lineage_id;
transfer_event_id;
data_reference;
source_influence_state;
transfer_class;
policy_epoch;
protected_state_version.
An implementation relying on operating-system instrumentation must
account for the information-transfer paths it actually supports.
A kernel event alone does not necessarily reveal application-level
meaning or prove whether particular data influenced an AI model's
reasoning.
Where complete fine-grained tracking is unavailable, the system may
conservatively mark the receiving context as influenced and apply the
corresponding protected authorization restrictions.
11.6.16. WF-06.16 — Protected Event-Update Ordering
In a concurrent execution environment, information ingestion and
process creation may occur close together.
The implementation prevents an unauthorized gap in which a child
process receives influenced data but is assigned an incompatible
broader authorization state.
In one embodiment, lineage creation and influence-state inheritance
are coordinated through a protected event-generation mechanism.
The event-generation value is advanced when a protected influence-
state transition occurs.
A child-lineage record identifies the parent state version used for
inheritance.
If the required parent-state version cannot be established, the child
is assigned a conservative restricted state or the relevant
authorization is withheld pending reconciliation.
Das Expires 19 April 2027 [Page 262]
Internet-Draft Protected AI Execution Finality October 2026
The system may use protected locks, atomic compare-and-update
operations, serialized event processing, or another concurrency
mechanism appropriate to the protected state store.
A child process does not acquire broader authority merely because the
corresponding lineage-state update was delayed.
11.6.17. WF-06.17 — Influence-Based Authorization Degradation
The protected influence state modifies the authorization scope or
validation requirements applicable to later Candidate Acts.
Let:
BaseScope(p,a) denote the execution scope otherwise available to
execution context p for Candidate Act a;
InfluenceScope(L,a) denote the restrictions applicable to act a under
influence state L;
EffectiveScope(p,a) denote the actual scope available after applying
those restrictions.
A non-limiting rule is:
EffectiveScope(p,a) = BaseScope(p,a) ∩ InfluenceScope(L(p),a)
where:
∩ denotes the intersection of permitted operation sets.
Accordingly, the effective authorization scope cannot exceed either
the original permitted scope or the scope permitted by the protected
influence restrictions.
For example, a policy may permit an agent to retrieve public
information under ordinary authorization conditions.
After the agent ingests untrusted content containing an instruction
to transmit protected files, a subsequent sensitive file-export
operation may require additional protected approval or be prohibited.
A lower-risk operation, such as producing a bounded summary, may
remain permitted if the corresponding predicates succeed.
The system does not require every tainted process to be permanently
denied every operation.
Das Expires 19 April 2027 [Page 263]
Internet-Draft Protected AI Execution Finality October 2026
11.6.18. WF-06.18 — Removal of a Broader Authorization Lane
In one specific implementation, the protected policy defines a
restricted automatic authorization lane for particular operation
classes.
Such a lane may be available only when required source-influence,
workload, operation, and protected-state conditions are satisfied.
Upon detecting a defined untrusted-information interaction, LM-605
updates the influence state.
The updated influence state causes subsequent operations to become
ineligible for the broader lane where the protected policy so
requires.
A representative rule is:
AutoLaneEligible(p,a) =
BaseEligible(p,a)
AND CleanForClass(L(p),a)
AND StateCurrent(p)
where:
AutoLaneEligible denotes eligibility for the restricted automatic
authorization lane;
BaseEligible denotes whether the operation otherwise qualifies for
that lane;
CleanForClass denotes whether the current influence state satisfies
the required conditions for the operation class;
StateCurrent denotes whether the required protected state and policy
epoch remain valid.
If AutoLaneEligible is false, the operation is not permitted through
that lane.
The operation may be denied or subjected to a different protected
authorization procedure, including explicit approval where permitted.
Das Expires 19 April 2027 [Page 264]
Internet-Draft Protected AI Execution Finality October 2026
Even when a lane is available, the corresponding Finality Sink
remains subject to the execution-capability requirements imposed by
the applicable embodiment.
11.6.19. WF-06.19 — Candidate Act Formation Following Untrusted Input
An influenced process or agent may propose a subsequent consequential
operation.
Examples include:
(a) a shell command;
(b) a network request;
(c) a credential-mediated connector call;
(d) a memory write;
(e) a model or workflow mutation;
(f) a database update;
(g) an autonomous purchase;
(h) a delegated-agent task;
(i) a file operation; or
(j) another externally effective act.
The operation is classified as Candidate Act CA-614.
The Candidate Act Descriptor includes or securely references the
required source-lineage and influence-state information.
An illustrative descriptor comprises:
candidate_act_id;
requesting_workload;
requesting_lineage_id;
operation_class;
destination;
Das Expires 19 April 2027 [Page 265]
Internet-Draft Protected AI Execution Finality October 2026
operation_parameters;
input_provenance_root;
taint_lineage_reference;
ITBO_reference;
CBR_reference;
influence_state_version;
policy_epoch;
authority_reference;
finality_sink_id.
The Candidate Act remains in a Non-Effective State until the required
protected validation is complete.
11.6.20. WF-06.20 — Candidate Act Provenance and Influence Validation
PED-609 receives or reconstructs the Candidate Act Descriptor and the
required protected influence-state references.
The PED evaluates whether the act depends upon an unauthorized
promotion of lower-trust content into execution authority.
The validation may distinguish:
(a) data used as evidence;
(b) data used as permitted operation parameters;
(c) content used as an instruction;
(d) content attempting to modify authority;
(e) content influencing a protected credential operation;
(f) content attempting to alter workflow or policy state; and
(g) content whose influence cannot be established to the level
required by the applicable authority.
Das Expires 19 April 2027 [Page 266]
Internet-Draft Protected AI Execution Finality October 2026
A retrieved document may be permitted to supply factual information
for summarization without being permitted to command the agent to
send credentials or modify protected policy.
Where the act depends on an unauthorized instruction source, the ITBO
predicate fails.
Where the required provenance or influence state cannot be verified,
the affected act remains non-effective.
11.6.21. WF-06.21 — Instruction Taint Boundary Predicate
The protected ITBO predicate evaluates whether the Candidate Act is
consistent with the permitted instruction hierarchy and influence
restrictions.
Let:
D denote the Candidate Act Descriptor;
I denote the applicable protected ITBO;
L denote the protected influence state;
A denote the applicable Authority Object;
S denote the required protected authorization state.
An illustrative predicate is:
Ptaint = AllowedInfluence(D,I,L,A,S)
where:
Ptaint denotes the taint and instruction-authority validation result;
AllowedInfluence denotes the protected procedure that evaluates
whether the sources influencing the proposed act may legitimately
contribute to that operation.
The predicate may return true for an authorized summarization of
untrusted material while returning false for an unauthorized command
derived from the same material.
This distinguishes the presence of untrusted input from unauthorized
reliance upon that input as execution authority.
Das Expires 19 April 2027 [Page 267]
Internet-Draft Protected AI Execution Finality October 2026
Where probabilistic prompt-injection classifiers are used, their
results may form part of the predicate inputs, but do not
independently release the execution capability.
11.6.22. WF-06.22 — Protected Trust Elevation
Some lower-trust content may legitimately need to contribute
instructions or operation parameters within an authorized scope.
In an embodiment employing the original DAS Trust Elevation Token
mechanism, a protected authority issues or verifies a token
authorizing a defined elevation.
The token may bind:
source_identity;
content_digest;
requested_trust_tier;
permitted_instruction_scope;
permitted_tool_scope;
permitted_act_class;
authority_issuer;
CBR_reference;
session_authority_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry.
PED-609 verifies the token against the corresponding source content,
required issuer authority, requested elevation scope, and current
protected state.
Successful elevation applies only within the permitted bounds.
Das Expires 19 April 2027 [Page 268]
Internet-Draft Protected AI Execution Finality October 2026
A token authorizing one document's structured routing information
does not automatically elevate all content read by the same process.
Trust elevation does not permit violation of mandatory higher-tier
authority constraints.
11.6.23. WF-06.23 — Protected Revalidation and Influence-State Reset
In certain embodiments, a protected recovery procedure may permit the
creation of a new execution context or the reclassification of a
bounded context after satisfying specified conditions.
Such conditions may include:
(a) termination of the influenced execution context;
(b) creation of a fresh isolated workload;
(c) removal of inherited untrusted context from the new workload;
(d) verification of the new workload's identity or configuration;
(e) re-establishment of protected authority;
(f) reconciliation of pending Candidate Acts;
(g) advancement of an authorization-state version; and
(h) issuance of new scoped capabilities where permitted.
An agent cannot restore broader authority merely by clearing a user-
space taint flag, changing its process name, restarting a tool, or
copying its own state into a newly spawned process.
Where the required clean-context conditions cannot be established,
the corresponding restricted influence state remains applicable.
11.6.24. WF-06.24 — Binding Influence State to the Scoped Execution
Capability
Following successful protected validation, PED-609 performs the
required protected-state and validation-evidence commitment
operations.
The corresponding scoped non-bearer execution capability may be bound
to:
candidate_act_digest;
Das Expires 19 April 2027 [Page 269]
Internet-Draft Protected AI Execution Finality October 2026
requesting_lineage_id;
influence_state_version;
ITBO_commitment;
CBR_reference;
authorization_scope;
policy_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_id.
An illustrative capability commitment is:
C = Auth_PED(D, Lversion, Iroot, Scope, Epoch, F, N)
where:
C denotes the authenticated execution capability or protected
capability reference;
Auth_PED denotes an authenticated capability-generation procedure
controlled by the PED;
D denotes the authorized Candidate Act Descriptor or its digest;
Lversion denotes the protected influence-state version associated
with the validated operation;
Iroot denotes the required ITBO or context-trust commitment;
Scope denotes the permitted execution scope;
Epoch denotes the applicable protected policy epoch;
F denotes the authorized Finality Sink;
N denotes a nonce or other required freshness value.
Das Expires 19 April 2027 [Page 270]
Internet-Draft Protected AI Execution Finality October 2026
The particular authentication mechanism may employ a signature, MAC,
sealed capability, protected register, or equivalent enforcement-
controlled artifact.
The capability remains subject to the relevant Finality Sink
verification.
11.6.25. WF-06.25 — Prevention of Stale Broader-Authority Reuse
If a process's influence state changes after a capability has been
prepared or issued, the system determines whether the changed state
invalidates a mandatory capability condition.
For example, a capability may have been authorized while a process
satisfied a restricted clean-context condition.
The process subsequently ingests untrusted instructions, causing the
protected influence-state version to advance.
Where the capability requires the earlier clean-context condition,
the capability is no longer accepted for effectuation under the
incompatible state.
An illustrative verification rule is:
StateMatch =
Compatible(C.lineage_version, CurrentLineageState)
AND PolicyCurrent(C.policy_epoch)
AND ScopeStillValid(C,CurrentLineageState)
where:
StateMatch denotes whether the capability remains valid under the
required protected influence and authorization state;
C.lineage_version denotes the influence-state version bound to the
capability;
CurrentLineageState denotes the current protected lineage state;
PolicyCurrent verifies the applicable policy epoch condition;
ScopeStillValid verifies that the capability's permitted operation
remains authorized under the current required influence restrictions.
Das Expires 19 April 2027 [Page 271]
Internet-Draft Protected AI Execution Finality October 2026
A changed lineage-state version does not necessarily invalidate every
capability if the applicable policy expressly permits compatible
state transitions.
Where the changed state removes the authority required for the act,
the Finality Sink rejects the affected capability.
11.6.26. WF-06.26 — Independent Finality Sink Verification
FS-612 receives the Candidate Act and its corresponding execution
capability.
The Finality Sink verifies the required operation, execution context,
authority scope, protected state, and influence-state binding.
An illustrative finality predicate is:
Permit =
Auth(C)
AND ActMatch(C,Dactual)
AND InfluenceValid(C,Lcurrent)
AND ScopeValid(C,A)
AND StateValid(C,S)
AND SinkValid(C,F)
where:
Permit denotes permission to perform the governed consequential
operation;
Auth verifies capability authenticity;
ActMatch verifies correspondence with the actual Candidate Act;
InfluenceValid verifies the required protected lineage and influence-
state conditions;
ScopeValid verifies the permitted operation under the Authority
Object;
StateValid verifies the required policy, revocation, freshness, and
capability-consumption state;
Das Expires 19 April 2027 [Page 272]
Internet-Draft Protected AI Execution Finality October 2026
SinkValid verifies the applicable Finality Sink identity;
Dactual denotes the operation actually presented for effectuation;
Lcurrent denotes the required current protected influence state;
S denotes protected authorization state;
F denotes the Finality Sink performing verification.
If any mandatory condition fails, the Candidate Act remains non-
effective through the governed execution path.
11.6.27. WF-06.27 — Concrete Process-Lineage Example
In one illustrative implementation, an AI agent runs within an
isolated container and is authorized to summarize public webpages.
The agent's protected authorization policy permits web retrieval and
bounded summarization.
Certain sensitive operations, including credential-backed document
export and privileged host modification, require separate
authorization and are not permitted solely through the ordinary
retrieval workflow.
The agent retrieves a webpage through a controlled browser or
retrieval connector.
The retrieved material contains an embedded instruction directing the
agent to transmit a confidential local file to an external
destination.
The retrieval component records the source identity and content
digest.
The protected ITBO classifies the material as lower-trust evidence-
only content and records the attempted instruction-authority
promotion.
The protected influence-state manager updates the agent session's
influence state with the applicable untrusted-web-content and
instruction-attempt labels.
The agent subsequently creates a child tool process to perform a
proposed action.
Das Expires 19 April 2027 [Page 273]
Internet-Draft Protected AI Execution Finality October 2026
The protected lineage manager associates the child process with the
parent's protected influence state.
The inherited state does not permit the child to regain a broader
execution scope merely by executing in a separate process.
The child attempts to invoke a connector that would transmit the
confidential file.
The connector request is intercepted and classified as a Candidate
Sandbox Egress Act.
The Candidate Act Descriptor identifies the requested operation,
destination, file reference, requesting workload, child-lineage
identity, influence-state reference, policy epoch, and applicable
Finality Sink.
The PED obtains the relevant Authority Object, ITBO, source-
provenance information, and protected lineage record.
The protected validation determines that the attempted file
transmission relies upon untrusted content acting outside its
authorized evidence role and that the requested operation is outside
the applicable authority scope.
The protected predicate fails.
No valid scoped execution capability is released for the rejected
operation.
The network or connector Finality Sink therefore refuses the proposed
transmission.
The agent may continue performing a permitted summary of the webpage
if the corresponding authorized operation satisfies its own required
protected predicates.
The system does not equate reading the webpage with authorization to
obey instructions embedded in it.
11.6.28. WF-06.28 — Process-Lineage Implementation Variants
The influence-state mechanism may be implemented through several
alternative technical arrangements.
Das Expires 19 April 2027 [Page 274]
Internet-Draft Protected AI Execution Finality October 2026
Kernel-assisted variant: Operating-system event hooks, kernel
security modules, process-creation mediation, or suitable eBPF
mechanisms provide event information or enforcement for selected
file, process, socket, and IPC operations. A protected state service
maintains the corresponding authorization-relevant lineage state.
Hypervisor-assisted variant: A hypervisor or protected virtual-
machine service associates execution contexts and selected
information-transfer events with protected lineage records.
Application-runtime variant: A trusted agent runtime or tool broker
records retrieval, context ingestion, tool invocation, worker
creation, and session propagation events.
Connector-mediated variant: All governed retrieval and connector-
response interfaces assign protected provenance records and update
the consuming workload's influence state.
Hybrid variant: Application-level provenance tracking is combined
with operating-system event monitoring and protected effectuation
gating.
Session-based variant: The influence state is associated with an AI
session, model context, or tool-execution session rather than an
individual operating-system process.
These implementations may provide different levels of granularity and
completeness.
A low-level process monitor does not automatically establish semantic
attribution of individual model outputs.
The embodiment therefore specifies the events and data paths on which
its influence guarantee depends.
11.6.29. WF-06.29 — Completeness and Conservative Attribution
In certain implementations, the system may not be able to identify
precisely which model token, webpage sentence, or memory fragment
causally influenced a generated action.
Where exact causal attribution is unavailable, the system may
conservatively maintain influence labels for all lower-trust material
admitted into the relevant model context or execution lineage.
For example, a session that incorporates an untrusted document may be
treated as influenced by that document for subsequent operations
governed by the corresponding policy.
Das Expires 19 April 2027 [Page 275]
Internet-Draft Protected AI Execution Finality October 2026
The system may permit lower-risk actions without requiring complete
causal-source proof, while requiring stronger provenance verification
or separate authorization for sensitive consequences.
An embodiment claiming comprehensive process-lineage tracking must
also address relevant data-ingestion and transfer paths, including
shared memory, inherited file descriptors, persistent files, workload
restoration, IPC, and alternative tool channels.
If a required monitoring path is unavailable or untrusted, the
protected enforcement mechanism withholds the affected authority or
applies the designated conservative restrictions.
The system does not claim perfect semantic influence attribution
merely from process-level monitoring.
11.6.30. WF-06.30 — Crash, Restart, and Lineage-State Continuity
Protected influence state is maintained so that an untrusted process
cannot restore broader authorization by crashing or restarting.
Where process identifiers are reused, the lineage manager
distinguishes different process generations.
Where a virtual machine or container is restored from a snapshot, the
implementation reconciles the restored execution context with the
protected lineage and authorization state.
Previously invalidated or consumed capabilities are not restored
merely because a saved runtime image contains an older
representation.
A restarted process or recovered agent session receives the influence
state required by the applicable protected recovery rules.
Where a required lineage state cannot be reconstructed consistently,
subsequent affected Candidate Acts remain non-effective pending
protected revalidation.
11.6.31. WF-06.31 — Failure and Fail-Closed Handling
The system refuses an affected Candidate Act when a mandatory
influence or authority condition cannot be verified.
Non-limiting failures include:
(a) missing required provenance;
Das Expires 19 April 2027 [Page 276]
Internet-Draft Protected AI Execution Finality October 2026
(b) invalid CBR authentication;
(c) inconsistent ITBO;
(d) unauthorized instruction elevation;
(e) missing protected lineage state;
(f) unverifiable parent-child relationship;
(g) failed required influence-state propagation;
(h) stale lineage-state version;
(i) unauthorized authority-scope expansion;
(j) unavailable required protected event state;
(k) incompatible policy epoch;
(l) invalid capability;
(m) operation mismatch; or
(n) failed Finality Sink verification.
Where permitted, the operation may be retained for review, denied,
quarantined, or subjected to a separately authorized revalidation
procedure.
A prompt-injection classifier result, ordinary audit record, or
process taint flag does not independently authorize a consequential
operation.
11.6.32. WF-06.32 — PHOSITA Verification and Negative Tests
The described implementation may be evaluated through controlled
process, session, provenance, and authorization tests.
Test 1 — Authorized evidence use: Supply an untrusted document for
summarization. Verify that the document may be used as permitted
evidence without obtaining instruction authority.
Test 2 — Embedded instruction attack: Include an instruction to
transmit protected data in lower-trust content. Verify that the
required ITBO predicate rejects the unauthorized Candidate Act.
Das Expires 19 April 2027 [Page 277]
Internet-Draft Protected AI Execution Finality October 2026
Test 3 — Process inheritance: Cause an influenced parent process to
create a child. Verify that the required influence labels are
inherited.
Test 4 — Subprocess execution: Cause an influenced process to invoke
a shell or replace its executable image. Verify that the required
lineage restrictions are not automatically cleared.
Test 5 — IPC propagation: Transfer lower-trust information to another
process through a monitored IPC channel. Verify the required
receiving-lineage update.
Test 6 — Session propagation: Spawn a subordinate agent or tool
session with influenced context. Verify the required state
association.
Test 7 — Authorization degradation: Attempt an operation previously
eligible for a broader authorization lane after a disqualifying
influence event. Verify that the broader lane is unavailable.
Test 8 — Valid trust elevation: Supply a protected Trust Elevation
Token covering a specific permitted source and operation. Verify
authorization only within the token's scope.
Test 9 — Invalid trust elevation: Modify the content or requested
elevation scope. Verify token rejection.
Test 10 — Agent-controlled taint reset: Attempt to clear the
influence state through an untrusted agent-controlled interface.
Verify that protected state remains authoritative.
Test 11 — Process identifier reuse: Terminate a process and create
another with a reused process identifier. Verify that lineage
generation prevents identity confusion.
Test 12 — Concurrent ingestion and spawn: Cause untrusted information
ingestion concurrently with child creation. Verify that the
protected state protocol prevents an unauthorized broader child
scope.
Test 13 — Capability-state race: Issue a capability, then update the
influence state before effectuation. Verify that the Finality Sink
enforces the required current state.
Test 14 — Snapshot restoration: Restore an earlier execution snapshot
and attempt to reuse an invalidated capability. Verify refusal under
protected state.
Das Expires 19 April 2027 [Page 278]
Internet-Draft Protected AI Execution Finality October 2026
Test 15 — Monitoring failure: Disable a monitoring component needed
for a mandatory influence predicate. Verify fail-closed handling of
the affected operation.
Test 16 — Bounded permitted action: Following ingestion of untrusted
material, propose an operation permitted under the restricted scope.
Verify that successful protected validation may still authorize that
operation.
Test 17 — Cross-lineage capability misuse: Present an operation-
specific capability from another execution lineage. Verify rejection
where lineage identity is mandatory.
Test 18 — Downstream Finality Sink: Verify that the actual externally
effective operation cannot proceed merely because an upstream process
or model completed computation.
These tests may use isolated processes, mock retrieval sources,
controlled prompts, process-creation instrumentation, protected
lineage records, test connectors, and fault-injection facilities.
11.6.33. WF-06.33 — Technical Effect
The embodiment establishes protected control over the relationship
between untrusted information, subsequent computation, execution-
lineage state, and externally effective operations.
The protected relationship may comprise:
(a) source identification;
(b) context-unit trust classification;
(c) CBR creation or verification;
(d) ITBO establishment;
(e) protected influence-state maintenance;
(f) process or session lineage association;
(g) defined information-interaction detection;
(h) protected influence-state propagation;
(i) authorization-scope degradation;
(j) prevention of unauthorized instruction promotion;
Das Expires 19 April 2027 [Page 279]
Internet-Draft Protected AI Execution Finality October 2026
(k) Candidate Act provenance binding;
(l) protected predicate validation;
(m) required protected-state and validation-evidence commitment;
(n) scoped execution-capability release; and
(o) independent Finality Sink verification.
The system prevents the mere ingestion of lower-trust information,
creation of a child process, continuation of an agent session, or
transfer of influenced context from independently expanding the
authority applicable to subsequent consequential operations.
The embodiment also distinguishes the use of untrusted material as
authorized evidence from its unauthorized use as an instruction or
execution-authority source.
The applicable protection is established by protected authorization
and finality verification, rather than by a prompt warning, heuristic
classification, or process label alone.
Computation is not authority to act.
Untrusted content is not instruction authority merely because an
agent has read it.
Process creation does not independently restore execution authority
restricted by protected influence state.
11.7. WF-07 — Protected Browser Automation, Computer-Use Actions,
Screen-State Finality Object, and GUI Effectuation Control
11.7.1. WF-07.1 — Technical Purpose
This embodiment provides a computer-implemented protected execution-
finality system for controlling consequential graphical user-
interface operations proposed by an artificial-intelligence agent,
browser-control agent, multimodal model, robotic process automation
system, desktop automation component, or other computer-use execution
environment.
A graphical action may become consequential through a mouse click,
touchscreen input, keystroke, form submission, browser command,
accessibility operation, terminal command, or equivalent input event.
Das Expires 19 April 2027 [Page 280]
Internet-Draft Protected AI Execution Finality October 2026
The architecture prevents a proposed governed graphical operation
from becoming effective merely because the agent possesses permission
to control a browser, desktop, application, virtual display, or
operating-system input interface.
Instead, the proposed operation is classified as a Candidate Act and
maintained in a Non-Effective State.
A Protected Enforcement Domain validates the proposed operation
against the contemporaneous screen state, semantic target identity,
geometric target location, application context, applicable Authority
Object, protected policy state, and required freshness conditions.
The protected system generates a Screen-State Finality Object (SSFO),
commits the required validation evidence, and releases or makes
available a scoped, non-bearer screen-action capability.
A GUI Finality Sink independently verifies the capability and
required current screen-state conditions immediately before
permitting the governed action.
The embodiment addresses stale screenshots, target substitution,
coordinate hallucination, interface movement, malicious overlays,
spoofed accessibility data, focus changes, user-interface race
conditions, and unauthorized promotion of visible page content into
execution authority.
11.7.2. WF-07.2 — Participating Technical Components
In one non-limiting implementation, the system comprises:
AE-701 — Computer-Use Agent Execution Environment
An artificial-intelligence agent, browser-use runtime, GUI automation
system, virtual-machine session, multimodal agent, or associated tool
configured to propose graphical actions.
IM-702 — GUI Action Interception Component
An enforcement-controlled component configured to receive proposed
interface actions before they are dispatched through a governed input
or application-command interface.
HQ-703 — Non-Effective Action Holding Mechanism
A staging queue or protected action record maintaining the proposed
graphical operation pending authorization.
Das Expires 19 April 2027 [Page 281]
Internet-Draft Protected AI Execution Finality October 2026
SC-704 — Screen-State Capture Component
A component configured to obtain a contemporaneous representation of
the relevant graphical interface.
SM-705 — Semantic Interface Measurement Component
A component configured to obtain or verify structured information
concerning interface elements, including their identifiers, roles,
labels, visibility, geometry, enabled state, and application context.
HT-706 — Geometric Hit-Test Component
A mechanism configured to determine which interface element would
receive the proposed graphical input.
DC-707 — Screen-Action Descriptor Component
A component configured to construct a canonical descriptor of the
proposed interface action.
PED-708 — Protected Enforcement Domain
A protected authorization component configured to validate screen-
state, semantic, geometric, purpose, risk, authority, and freshness
predicates.
PS-709 — Protected Authorization-State Store
A mechanism maintaining applicable policy epochs, user authorization,
revocation state, nonce state, operation identifiers, and capability-
consumption information.
SO-710 — Screen-State Finality Object Component
A protected mechanism configured to construct, authenticate, and
maintain the SSFO or its protected commitment.
EV-711 — Protected Validation-Evidence Component
A mechanism configured to generate or commit an applicable LAVR, AVR,
authenticated validation record, or equivalent protected evidence.
CR-712 — Screen-Action Capability Release Component
A mechanism configured to release or make available the scoped non-
bearer capability associated with the validated action.
Das Expires 19 April 2027 [Page 282]
Internet-Draft Protected AI Execution Finality October 2026
FS-713 — GUI Finality Sink
An enforcement-controlled browser, operating-system, application,
terminal, or input-dispatch boundary configured to verify the
required capability before performing the governed interface action.
AD-714 — Controlled Action Dispatcher
A mechanism configured to dispatch the permitted input event or
application command through the verified interface.
OS-715 — Protected Action-Outcome State Component
A component configured to maintain action completion, denial, replay,
or indeterminate-outcome information.
UA-716 — Trusted User Authorization Component
An optional protected interface for obtaining explicit user
confirmation required for high-risk graphical operations.
The components may be implemented within one protected node or
distributed among a browser runtime, operating system, hypervisor,
trusted UI subsystem, protected controller, or other authenticated
execution components.
11.7.3. WF-07.3 — Identification of the GUI Effectuation Boundary
The system first identifies where a proposed computer-use action
becomes consequential.
The applicable interface may comprise:
(a) a browser automation action dispatcher;
(b) an operating-system input dispatcher;
(c) an accessibility action interface;
(d) a terminal command gateway;
(e) an application command controller;
(f) a mobile-device UI automation interface;
(g) a virtual or remote desktop input gateway;
(h) a secure UI controller;
Das Expires 19 April 2027 [Page 283]
Internet-Draft Protected AI Execution Finality October 2026
(i) a file-selection or file-operation dialog;
(j) a payment or purchase-confirmation interface; or
(k) another interface capable of producing a governed operation.
A proposed click may first become effective as an input event at a
GUI boundary. A subsequent network request, database commitment,
payment or other downstream consequence may have its own separate
Finality Sink.
The architecture identifies the boundary actually controlled by FS-
713.
A GUI input capability does not automatically substitute for an
additional downstream execution capability where the corresponding
operation requires separate finality enforcement.
11.7.4. WF-07.4 — Mandatory GUI Action Mediation
Before enabling governed computer-use operations, the system
configures the execution environment so that AE-701 cannot
independently dispatch restricted graphical actions through an
alternative unverified path.
In a browser implementation, the agent may be restricted to an
enforcement-controlled browser automation interface.
In a desktop implementation, the agent may be prohibited from
directly invoking unrestricted operating-system input-injection
facilities.
In a mobile implementation, the protected mediation mechanism may
control the relevant accessibility action, UI automation, or secure-
input interface.
In a remote-desktop implementation, the input-control channel may
terminate at an authenticated remote-action gateway that performs the
required verification.
The system also governs alternative action channels capable of
producing the same consequential effect, such as direct script
execution, DOM-triggered commands, browser extensions, application
APIs, or tool calls, according to the relevant effectuation-path
requirements.
Das Expires 19 April 2027 [Page 284]
Internet-Draft Protected AI Execution Finality October 2026
A protected GUI gate does not establish universal non-bypassability
if the agent retains an unrestricted alternative interface capable of
performing the same governed operation.
11.7.5. WF-07.5 — Candidate GUI Action Generation
AE-701 generates a proposed action.
Non-limiting examples include:
(a) clicking a button;
(b) tapping a touchscreen target;
(c) submitting a form;
(d) entering information into an application field;
(e) pressing a keyboard shortcut;
(f) selecting a file;
(g) confirming a purchase;
(h) changing an account permission;
(i) submitting an email;
(j) running a terminal command;
(k) approving an application dialog;
(l) deleting an account;
(m) modifying a cloud resource through a dashboard; or
(n) performing another computer-use operation.
The proposed operation is designated Candidate GUI Act CA-717.
Generation of CA-717 does not independently authorize the action.
11.7.6. WF-07.6 — Interception and Non-Effective Staging
IM-702 intercepts CA-717 before the governed effectuation interface
receives the input.
The proposed action is retained in HQ-703.
Das Expires 19 April 2027 [Page 285]
Internet-Draft Protected AI Execution Finality October 2026
A non-limiting pending-action record comprises:
operation_id;
agent_identity;
session_identity;
application_identity;
window_identity;
proposed_action_type;
declared_target;
proposed_coordinates;
declared_semantic_intent;
requested_effect_class;
authority_reference;
policy_epoch;
status = NON_EFFECTIVE.
The agent may revise or cancel the proposed action while it remains
non-effective.
A materially changed proposed action requires corresponding
descriptor validation rather than silently inheriting authority from
the earlier proposal.
11.7.7. WF-07.7 — Contemporaneous Screen-State Capture
SC-704 captures or measures the relevant interface state before
authorization.
The captured state may comprise:
(a) a full-screen image;
(b) an active-window image;
(c) a screenshot of the target region;
Das Expires 19 April 2027 [Page 286]
Internet-Draft Protected AI Execution Finality October 2026
(d) a browser-tab rendering measurement;
(e) a terminal-screen measurement;
(f) a secure-compositor measurement;
(g) a framebuffer digest;
(h) a Merkleized screen-tile map; or
(i) an equivalent protected visual-state representation.
A protected capture record may comprise:
screen_capture_id;
screen_digest;
capture_generation;
active_window_id;
application_id;
display_id;
viewport_geometry;
display_scaling;
scroll_position;
focus_state;
policy_epoch;
nonce;
capture_freshness_reference.
The capture is associated with the interface context relevant to the
proposed action.
The protected system does not assume that an arbitrary screenshot
supplied by the agent accurately represents the current effectuation
interface.
Das Expires 19 April 2027 [Page 287]
Internet-Draft Protected AI Execution Finality October 2026
Where stronger integrity is required, the screen-state measurement is
obtained from an authenticated rendering or display subsystem.
11.7.8. WF-07.8 — Screen-State Digest
An illustrative screen-state digest may be computed as:
Hs = H("DAS-SCREEN-v1" || Encode(Frame, Geometry, Window,
Generation))
where:
Hs denotes the screen-state digest;
H denotes an approved cryptographic hash function;
Encode denotes a deterministic byte-encoding procedure;
Frame denotes the captured or measured screen pixels or protected
screen-state reference;
Geometry denotes the relevant viewport and display-coordinate
configuration;
Window denotes the authenticated active-window or display context;
Generation denotes the protected screen-state version or capture
generation;
|| denotes concatenation.
The screen-state digest may instead be computed over a bounded
rendered region or an authenticated Merkle-root representation where
the applicable policy permits such granularity.
Where unrelated dynamic interface regions change frequently, the
system may define a protected target-region measurement rather than
requiring exact equality of every pixel of the entire display.
Any permitted exclusion must not omit information necessary to verify
the target's visibility, geometry, identity, or consequential effect.
11.7.9. WF-07.9 — Semantic Interface Measurement
SM-705 obtains structured information concerning the relevant
application interface.
Depending upon the implementation, this may comprise:
Das Expires 19 April 2027 [Page 288]
Internet-Draft Protected AI Execution Finality October 2026
(a) a DOM tree;
(b) an accessibility tree;
(c) a browser rendering tree;
(d) an application view hierarchy;
(e) a terminal command context;
(f) a secure UI descriptor;
(g) an operating-system automation tree;
(h) a mobile accessibility representation; or
(i) another semantic interface-state object.
The semantic representation may include:
element_id;
semantic_role;
accessible_label;
visible_text;
element_state;
bounding_region;
z_order;
focus_state;
application_identity;
browser_origin;
document_identity;
form_identity;
event_target_reference;
semantic_generation.
Das Expires 19 April 2027 [Page 289]
Internet-Draft Protected AI Execution Finality October 2026
Where required, the representation is authenticated or measured by a
trusted browser, accessibility, compositor, application, or protected
execution component.
An agent-supplied semantic label is not independently treated as
proof of the interface's actual meaning.
11.7.10. WF-07.10 — Semantic-State Commitment
The semantic interface representation may be canonicalized and
hashed.
An illustrative expression is:
Hm = H("DAS-SEMANTIC-v1" || Encode(Tree, Target, Context, Version))
where:
Hm denotes the semantic-state digest;
Tree denotes the relevant semantic-interface representation;
Target denotes the selected element identity and state;
Context denotes the application, origin, focus, and window context;
Version denotes the semantic-state generation or authenticated
version;
H, Encode, and || retain their previously defined meanings.
The protected system associates Hm with the corresponding rendered
screen-state measurement.
The relationship permits the PED to determine whether the semantic
target presented for authorization corresponds to the actual
interface state within the specified trust assumptions.
11.7.11. WF-07.11 — Coordinate-System Normalization
Graphical input locations may be represented in physical display
pixels, logical desktop pixels, browser viewport coordinates,
document coordinates, element-relative coordinates, or another
coordinate system.
DC-707 identifies the coordinate system used by the agent and the one
used by the actual input dispatcher.
Das Expires 19 April 2027 [Page 290]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative transformation is:
p_dispatch = T(p_agent)
where:
p_agent denotes the proposed action location in the agent's
coordinate system;
T denotes the specified coordinate transformation;
p_dispatch denotes the corresponding location in the input
dispatcher's coordinate system.
The transformation may account for:
(a) display scaling;
(b) device-pixel ratio;
(c) browser zoom;
(d) viewport offset;
(e) scroll position;
(f) window placement;
(g) nested frame geometry;
(h) element transforms;
(i) display rotation; and
(j) remote-desktop scaling.
The transformation parameters are included in, or bound to, the
protected screen-state representation where required.
If the relevant coordinate transformation cannot be established, the
operation remains non-effective.
11.7.12. WF-07.12 — Geometric Target Verification
HT-706 identifies the interface element expected to receive the
proposed input.
For a rectangular target region:
Das Expires 19 April 2027 [Page 291]
Internet-Draft Protected AI Execution Finality October 2026
R = [xmin, xmax] × [ymin, ymax]
where:
R denotes the target bounding region;
xmin and xmax denote the horizontal boundaries;
ymin and ymax denote the vertical boundaries;
× denotes the Cartesian product of coordinate intervals.
For a proposed pointer location p = (x,y), basic region membership
may be evaluated as:
Inside(p,R) =
(xmin ≤ x ≤ xmax)
AND
(ymin ≤ y ≤ ymax)
where:
Inside(p,R) denotes whether the proposed coordinate lies within the
region.
However, region membership alone is not sufficient when overlapping
elements, transforms, clipping, transparent overlays, or event-
dispatch rules can change the actual receiving target.
The implementation therefore determines the actual effective hit
target using a trusted hit-test procedure appropriate to the
rendering environment.
For irregular targets, the implementation may use point-in-polygon
testing, compositor hit testing, DOM hit testing, or another suitable
procedure.
11.7.13. WF-07.13 — Semantic-Geometric Equivalence
The protected system compares the declared semantic action with the
actual target of the proposed input.
Let:
I denote the declared semantic intent;
Das Expires 19 April 2027 [Page 292]
Internet-Draft Protected AI Execution Finality October 2026
Ehit denote the element that would actually receive the input;
Role(Ehit) denote the verified semantic or functional role of the
target;
AllowedRole(I) denote the role or effect class authorized by the
applicable Authority Object.
A representative predicate is:
Pgeom = TargetValid(Ehit) AND RoleMatch(Role(Ehit),AllowedRole(I))
where:
Pgeom denotes the semantic-geometric validation result;
TargetValid verifies the target's required visibility, enabled state,
focus relationship, and geometric eligibility;
RoleMatch verifies correspondence to the intended authorized semantic
operation.
For example, a proposed action described as selecting “Save” fails
when the protected hit test identifies a “Delete” control.
Likewise, an action described as canceling a payment fails if the
effective target is a payment-confirmation control.
The protected system does not authorize an input based solely on the
agent's declared interpretation of the screen.
11.7.14. WF-07.14 — Overlay, Z-Order, and Occlusion Verification
A target may geometrically occupy the proposed coordinate but be
partially or completely obscured by another interface element.
Accordingly, the protected system may verify:
(a) the effective z-order;
(b) target visibility;
(c) clipping boundaries;
(d) active-window identity;
(e) iframe and embedded-frame relationships;
Das Expires 19 April 2027 [Page 293]
Internet-Draft Protected AI Execution Finality October 2026
(f) overlay elements;
(g) hit-test routing;
(h) focus state; and
(i) event-dispatch context.
Where the actual receiving element differs from the validated
semantic target, the semantic-geometric predicate fails.
An application-controlled overlay or malicious browser extension
cannot be treated as harmless merely because the underlying button
occupies the expected coordinates.
If the selected rendering environment cannot provide trustworthy
target identity, the implementation may require additional
verification or refuse the affected high-risk action.
11.7.15. WF-07.15 — Hardware-Rendered and Semantic Coherence
In stronger embodiments, the protected system verifies correspondence
between rendering evidence and semantic interface evidence.
The applicable measurements may originate from a protected
compositor, hardware-adjacent framebuffer, trusted rendering process,
secure UI subsystem, or equivalent component.
The verification may compare:
(a) rendered target appearance;
(b) semantic element identity;
(c) bounding geometry;
(d) target role;
(e) visible label;
(f) effective hit-test result;
(g) application identity; and
(h) target enabled or disabled state.
Das Expires 19 April 2027 [Page 294]
Internet-Draft Protected AI Execution Finality October 2026
A rendered button showing “Delete Account” is not automatically
treated as an authorized “Save” action merely because an untrusted
accessibility label claims otherwise.
Likewise, a semantic element identified as a payment confirmation is
not accepted if the actual rendered or interactive target is a
different control.
Where semantic and rendering evidence cannot be reconciled under the
required trust rules, the PED withholds the applicable capability.
No universal inference that pixels alone prove the true downstream
semantics of an arbitrary untrusted application is assumed.
11.7.16. WF-07.16 — Screen-Action Descriptor
DC-707 constructs a canonical Screen-Action Descriptor.
An illustrative descriptor contains:
action_id;
agent_identity;
session_identity;
application_identity;
browser_origin;
window_identity;
screen_state_digest;
semantic_state_digest;
target_element_identity;
target_bounding_region;
z_order_state;
focus_state;
proposed_coordinates;
coordinate_transform_reference;
Das Expires 19 April 2027 [Page 295]
Internet-Draft Protected AI Execution Finality October 2026
action_type;
action_parameters;
declared_semantic_intent;
verified_effect_class;
risk_class;
authority_reference;
user_approval_reference;
policy_epoch;
nonce;
expiry;
finality_sink_id.
The descriptor binds the proposed action to the interface state upon
which authorization depends.
A descriptor authorized for one target does not automatically
authorize another target, even if both targets are located in the
same application window.
11.7.17. WF-07.17 — Construction of the Screen-State Finality Object
SO-710 generates a Screen-State Finality Object from the required
screen, semantic, action, and authority information.
An illustrative representation is:
SSFO = AuthPED(Hs, Hm, Da, Target, Risk, Authority, Epoch, Nonce, F)
where:
SSFO denotes the protected Screen-State Finality Object;
AuthPED denotes the cryptographic or otherwise protected
authentication procedure controlled by the PED;
Hs denotes the screen-state digest;
Hm denotes the semantic-state digest;
Das Expires 19 April 2027 [Page 296]
Internet-Draft Protected AI Execution Finality October 2026
Da denotes the canonical Screen-Action Descriptor or its digest;
Target denotes the verified target element or region;
Risk denotes the applicable action-risk class;
Authority denotes the required authenticated authority context;
Epoch denotes the protected policy or execution epoch;
Nonce denotes a freshness or replay-prevention value;
F denotes the applicable GUI Finality Sink identity.
The SSFO may be implemented using an authenticated record, protected
register state, signed object, Merkle commitment, sealed structure,
or equivalent protected representation.
The SSFO is distinct from an ordinary screenshot, agent-generated
description, or post-event interaction log.
11.7.18. WF-07.18 — Application Context and Target-Origin Validation
For browser actions, the PED may verify the browser origin, active
tab, document identity, iframe origin, form identity, and applicable
destination.
For native applications, corresponding conditions may identify the
application executable, authenticated window, process identity,
command class, and resource context.
For mobile applications, the conditions may identify the foreground
application, active view, secure prompt, and permitted action scope.
For remote desktops, the system may verify the remote session
identity, displayed frame generation, target window, and controlled
remote-input interface.
An action prepared for one application, origin, or window is not
independently authorized for another.
If a browser navigation, tab switch, application replacement, or
focus change invalidates a mandatory binding, the corresponding
action requires revalidation.
Das Expires 19 April 2027 [Page 297]
Internet-Draft Protected AI Execution Finality October 2026
11.7.19. WF-07.19 — Purpose and Risk-Class Validation
PED-708 evaluates the actual proposed operation against the
applicable Authority Object and risk policy.
A risk class may identify operations such as:
(a) navigation without consequential state mutation;
(b) bounded data retrieval;
(c) local temporary editing;
(d) persistent file mutation;
(e) message transmission;
(f) credential entry or release;
(g) account-permission change;
(h) purchase or payment approval;
(i) deletion of persistent information;
(j) software installation;
(k) privileged command execution; or
(l) another governed effect class.
The applicable predicates depend upon the effect class and authorized
purpose.
A lower-risk operation may require a smaller mandatory predicate set,
while a higher-risk operation may require stronger target
attestation, additional protected state, or explicit user
confirmation.
Risk classification does not eliminate the Finality Sink verification
requirement for a governed Candidate Act.
11.7.20. WF-07.20 — Protected Human Authorization
Where explicit human authorization is required, UA-716 obtains an
approval artifact through a trusted authorization interface.
The approval artifact may bind:
Das Expires 19 April 2027 [Page 298]
Internet-Draft Protected AI Execution Finality October 2026
user_identity;
approved_action_digest;
screen_state_digest;
target_identity;
application_identity;
destination;
recipient;
transaction_amount;
approved_effect_class;
policy_epoch;
nonce;
expiry.
The authorization may be produced through a trusted UI confirmation,
passkey ceremony, secure prompt, hardware confirmation, or equivalent
mechanism.
The PED verifies that the approval applies to the actual Candidate
GUI Act.
A generic approval for “continue” does not authorize a materially
different recipient, transaction amount, application context, or
action target where those parameters are mandatory.
Human approval does not independently bypass protected validation or
Finality Sink verification.
11.7.21. WF-07.21 — Protected Predicate Evaluation
PED-708 evaluates the required screen-action authorization
predicates.
A representative conjunctive predicate is:
Vui =
Pscreen
Das Expires 19 April 2027 [Page 299]
Internet-Draft Protected AI Execution Finality October 2026
AND Psemantic
AND Pgeometry
AND Pcontext
AND Ppurpose
AND Prisk
AND Pauthority
AND Pfresh
where:
Vui denotes the protected UI authorization result;
Pscreen validates the required current rendered-screen state;
Psemantic validates the semantic interface representation;
Pgeometry validates geometric correspondence and the actual effective
target;
Pcontext validates the application, origin, window, and focus
context;
Ppurpose validates the authorized user purpose and operation scope;
Prisk validates the required risk-class conditions;
Pauthority validates applicable Authority Objects and approvals;
Pfresh validates nonce, expiry, policy epoch, revocation state, and
other required freshness conditions.
Each predicate is applied according to the selected embodiment and
Authority Object.
When any mandatory predicate fails, the PED withholds execution
authority.
11.7.22. WF-07.22 — Protected State and Validation-Evidence Commitment
Upon successful validation, PED-708 performs the required protected
state operations.
Das Expires 19 April 2027 [Page 300]
Internet-Draft Protected AI Execution Finality October 2026
Such operations may include:
(a) nonce reservation or consumption;
(b) authorization-state version advancement;
(c) policy-epoch validation;
(d) bounded action-budget consumption;
(e) user-approval consumption;
(f) protected usage-state reservation; and
(g) recording an SSFO commitment.
EV-711 generates or commits the required protected validation
evidence.
An illustrative evidence record comprises:
receipt_id;
candidate_action_digest;
SSFO_digest;
screen_state_digest;
semantic_state_digest;
verified_target;
authority_reference;
predicate_result_reference;
protected_state_transition;
policy_epoch;
nonce;
finality_sink_id;
protected_authentication.
Das Expires 19 April 2027 [Page 301]
Internet-Draft Protected AI Execution Finality October 2026
Where the applicable embodiment requires evidence commitment before,
or atomically with, capability availability, the implementation
preserves that ordering.
The SSFO and validation record may remain protected internally rather
than requiring publication to an external ledger.
11.7.23. WF-07.23 — Scoped Screen-Action Capability
CR-712 releases or makes available a scoped non-bearer Screen-Action
Capability only after the required protected finality transaction
succeeds.
An illustrative capability includes or securely references:
capability_id;
candidate_action_digest;
SSFO_digest;
screen_state_digest;
semantic_state_digest;
authorized_action_type;
target_element_identity;
authorized_target_region;
application_identity;
authorized_effect_class;
approval_reference;
policy_epoch;
nonce;
expiry;
usage_limit;
finality_sink_id.
Das Expires 19 April 2027 [Page 302]
Internet-Draft Protected AI Execution Finality October 2026
The capability is bound to the corresponding action and screen-state
requirements.
Possession of the capability representation does not authorize a
different target, application, effect class, or Finality Sink when
those conditions are mandatory.
The capability may be represented by an authenticated artifact,
protected handle, capability-table entry, secure dispatcher token, or
equivalent bounded enablement mechanism.
11.7.24. WF-07.24 — Immediate Pre-Dispatch Verification
FS-713 receives the proposed action and its corresponding capability.
Before dispatching the governed input event, FS-713 verifies:
(a) capability authenticity;
(b) correspondence to the proposed action;
(c) current required screen-state measurement;
(d) current semantic target identity;
(e) effective hit-test result;
(f) application and active-window identity;
(g) required browser-origin or application context;
(h) focus state;
(i) action type and parameters;
(j) user authorization where required;
(k) policy epoch and revocation state;
(l) nonce, expiry, and consumption conditions; and
(m) designated Finality Sink identity.
An illustrative decision expression is:
PermitUI =
Auth(C)
Das Expires 19 April 2027 [Page 303]
Internet-Draft Protected AI Execution Finality October 2026
AND ScreenMatch(C,Sactual)
AND TargetMatch(C,Tactual)
AND ContextMatch(C,Xactual)
AND StateValid(C,P)
AND SinkValid(C,F)
where:
PermitUI denotes permission to dispatch the governed UI action;
C denotes the scoped Screen-Action Capability;
Sactual denotes the current required screen state;
Tactual denotes the effective input target;
Xactual denotes the current application, window, focus, and execution
context;
P denotes the relevant protected policy and authorization state;
F denotes the designated GUI Finality Sink;
Auth verifies required capability authenticity;
ScreenMatch verifies correspondence with the authorized screen-state
measurement;
TargetMatch verifies the semantic and geometric target conditions;
ContextMatch verifies the required application and execution context;
StateValid verifies mandatory freshness, revocation, approval, and
consumption state;
SinkValid verifies the intended Finality Sink.
The action is dispatched only if PermitUI is true.
11.7.25. WF-07.25 — Time-of-Check and Time-of-Use Protection
A graphical interface may change between the time at which an agent
observes a screen and the time at which its proposed action is
executed.
Das Expires 19 April 2027 [Page 304]
Internet-Draft Protected AI Execution Finality October 2026
Potential changes include:
(a) moving buttons;
(b) new overlays;
(c) modal dialogs;
(d) focus changes;
(e) browser navigation;
(f) iframe replacement;
(g) responsive-layout changes;
(h) dynamic content insertion;
(i) application-window substitution; and
(j) delayed remote-desktop rendering.
The Finality Sink therefore verifies the required current state
immediately before input dispatch.
In a stronger implementation, the protected UI action transaction
coordinates final state verification, capability consumption, and
controlled input dispatch under a protected state or input-dispatch
synchronization mechanism.
For example, a trusted browser action broker may compare the current
target-generation identifier, reserve the authorization, and dispatch
the action against that exact authenticated target before allowing an
incompatible intervening target mutation.
Where the interface cannot provide such atomicity, the implementation
must use another sufficiently protective verification and
synchronization arrangement for the specified guarantee.
A check performed several seconds earlier does not automatically
establish current target validity at the instant of effectuation.
11.7.26. WF-07.26 — Protected Capability Consumption
Where the capability is single-use, the GUI Finality Sink consumes or
reserves the applicable protected usage state before permitting the
governed input event.
Das Expires 19 April 2027 [Page 305]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative transition is:
AUTHORIZED → RESERVED → DISPATCHED
where:
AUTHORIZED denotes a valid capability awaiting permitted use;
RESERVED denotes protected consumption or reservation of the
capability;
DISPATCHED denotes that the controlled input action was submitted to
the applicable GUI effectuation boundary.
If the input event is refused before dispatch, the operation may
enter a protected denial or recovery state.
If the event is dispatched but its downstream consequence remains
unknown, the system does not automatically treat that event as never
having occurred.
The protected operation outcome is maintained separately from the
authorization state.
11.7.27. WF-07.27 — Browser Form Submission Example
In one concrete embodiment, an AI agent is authorized to prepare an
email through a browser-based enterprise application.
The agent prepares a recipient address, subject, message body, and
proposed Send action.
The browser automation action is intercepted before submission.
The system constructs a Candidate GUI Act Descriptor identifying the
recipient, applicable message-content digest, authorized browser
origin, application identity, Send control, intended effect class,
and applicable Finality Sink.
SC-704 captures the relevant contemporaneous browser screen state.
SM-705 obtains the semantic identity of the recipient field, message
body, and Send control from the applicable trusted browser or UI
measurement interface.
HT-706 determines which control would receive the proposed click.
Das Expires 19 April 2027 [Page 306]
Internet-Draft Protected AI Execution Finality October 2026
The PED verifies that the actual target corresponds to Send rather
than Delete, Archive, Forward, or another operation.
Where required, the PED also verifies that the recipient and message
content correspond to the approved operation.
The PED commits the required validation evidence and releases a
screen-action capability bound to the SSFO.
Immediately before dispatch, the GUI Finality Sink checks the current
screen, target, application, and authorization state.
If the target has moved, a modal overlay has appeared, the recipient
has changed outside the authorized scope, or another mandatory
condition has become invalid, the action is refused.
If verification succeeds, the controlled dispatcher performs the
authorized Send action.
Where the consequential network transmission or receiving-side
message acceptance is separately governed, the corresponding network
or service Finality Sink also performs its required verification.
The GUI authorization does not automatically establish final remote
delivery merely because the browser accepted the click.
11.7.28. WF-07.28 — Payment-Confirmation and High-Risk Action Example
In another embodiment, a computer-use agent prepares an authorized
purchase through a graphical checkout interface.
The Candidate GUI Act identifies:
(a) the merchant or service;
(b) the intended transaction;
(c) transaction amount and currency;
(d) applicable recipient or payee;
(e) the confirmation control;
(f) the authorized user purpose;
(g) the contemporaneous screen and semantic state; and
(h) the payment-confirmation Finality Sink.
Das Expires 19 April 2027 [Page 307]
Internet-Draft Protected AI Execution Finality October 2026
The system measures the checkout interface and verifies that the
proposed action targets the intended confirmation control.
A user approval artifact, where required, binds the transaction
parameters and screen-state reference.
The PED validates the merchant, amount, recipient, applicable
authority scope, risk class, current policy, and freshness
conditions.
After protected state and evidence commitment, a scoped capability is
made available.
The GUI Finality Sink verifies the capability immediately before the
confirmation input.
If the displayed amount, merchant, effective target, active
application, or required user authorization differs from the
validated conditions, the confirmation action is withheld.
Where payment execution or settlement involves a separate
consequential boundary, a payment Finality Sink performs its own
required authorization verification.
This avoids treating permission to click a button as unconditional
permission to settle an unrelated transaction.
11.7.29. WF-07.29 — Terminal and Native-Application Variations
The same protected finality arrangement may govern terminal commands
and native application actions.
For terminal execution, the descriptor may bind the proposed command,
target terminal session, executable or command class, relevant
arguments, current focus, authorized purpose, and host execution
Finality Sink.
A keystroke that would cause execution of a destructive command is
withheld unless the required protected capability verifies.
For native desktop applications, the system may verify the
application identity, active window, accessibility target, relevant
geometry, and actual command interface.
For mobile applications, it may verify the foreground application,
permitted view, action target, secure UI state, and applicable user
authorization.
Das Expires 19 April 2027 [Page 308]
Internet-Draft Protected AI Execution Finality October 2026
For remote desktops, it may associate the action with an
authenticated remote-session identity, captured remote frame,
relevant input-coordinate transformation, and controlled remote-input
dispatcher.
The implementation identifies and protects the actual input or
command boundary at which the proposed operation becomes effective.
11.7.30. WF-07.30 — Failure and Fail-Closed Handling
The protected system refuses the affected GUI operation when any
mandatory condition fails.
Non-limiting failure conditions include:
(a) missing or invalid screen capture;
(b) stale screen state;
(c) unverifiable semantic interface state;
(d) semantic-geometric target mismatch;
(e) obscured or substituted action target;
(f) unauthorized browser-origin change;
(g) focus or active-window mismatch;
(h) invalid coordinate transformation;
(i) unauthorized action class;
(j) invalid or stale user approval;
(k) expired SSFO;
(l) policy-epoch or revocation mismatch;
(m) capability replay;
(n) unavailable required protected state;
(o) failed validation-evidence commitment; or
(p) failed GUI Finality Sink verification.
Das Expires 19 April 2027 [Page 309]
Internet-Draft Protected AI Execution Finality October 2026
The proposed operation remains in a Non-Effective State, is denied,
or is redirected to an explicitly authorized review procedure.
The protected system may generate a denial receipt identifying the
relevant mismatch.
Such a denial receipt does not itself authorize the rejected action.
11.7.31. WF-07.31 — Agent Context Correction After Denial
Where an action is refused, the system may communicate the denial
result to the agent through a controlled feedback channel.
The feedback may identify:
operation_id;
denial_class;
expected_target;
observed_target;
screen_state_version;
required_revalidation;
protected_denial_reference.
The agent may use this information to update its current plan or
obtain a new screen observation.
For example, if the agent proposes a click on a stale button
position, the protected system may indicate that the screen state
changed and that a new action descriptor is required.
The agent must not treat a rejected action as having succeeded.
In embodiments employing protected context correction, the denial
state is incorporated into the agent's subsequent execution context
before further affected tool or computer-use actions proceed.
11.7.32. WF-07.32 — Alternative Structural Implementations
Browser automation implementation: An enforcement-controlled browser
action broker verifies an SSFO-bound capability before performing a
governed click, form submission, navigation, or script-mediated
action.
Das Expires 19 April 2027 [Page 310]
Internet-Draft Protected AI Execution Finality October 2026
Operating-system implementation: A protected input dispatcher
mediates designated keyboard, pointer, or accessibility actions.
Trusted compositor implementation: A secure compositor or hardware-
adjacent rendering source produces trusted screen measurements and
supports final target verification.
Hypervisor implementation: A virtual machine supplies proposed
computer-use actions to a protected host or virtual-device
controller.
Remote-desktop implementation: An authenticated remote-input gateway
verifies action capabilities against the relevant remote screen
generation and session identity.
Mobile implementation: A protected mobile UI automation or
accessibility interface mediates governed actions.
Single-node implementation: The screen-state capture, PED, capability
mechanism, and GUI Finality Sink operate within one protected device
or node.
Distributed implementation: A protected authority performs validation
remotely, while a local or receiving-side GUI Finality Sink verifies
the resulting capability before executing the governed action.
These implementations may have different levels of resistance to
malicious applications, compromised accessibility frameworks, display
spoofing, privileged software compromise, or hardware attack.
A software-only screenshot comparison does not automatically provide
the guarantees of a hardware-rooted screen measurement.
11.7.33. WF-07.33 — PHOSITA Verification and Negative Tests
A person having ordinary skill in browser automation, GUI security,
operating-system input mediation, accessibility frameworks, trusted
rendering systems, or protected execution may verify the embodiment
through the following tests.
Test 1 — Correct authorized target: The current screen, semantic
identity, target geometry, and capability match. The authorized
input is dispatched.
Test 2 — Coordinate hallucination: The proposed coordinate does not
intersect the declared target. The action is refused.
Das Expires 19 April 2027 [Page 311]
Internet-Draft Protected AI Execution Finality October 2026
Test 3 — Changed layout: The target moves after authorization. The
required screen-state or target correspondence fails.
Test 4 — Overlay attack: An overlay becomes the effective input
target. The actual hit-test mismatch prevents the governed action.
Test 5 — Focus theft: Another window receives focus before input
dispatch. The required application-context predicate fails.
Test 6 — Browser navigation: The browser navigates to a different
origin or document. An incompatible SSFO is rejected.
Test 7 — Accessibility spoofing: The semantic label does not
correspond to the required rendered or effective target. The
coherence predicate fails where mandatory.
Test 8 — Stale screenshot: A previously captured screen state is
presented after a relevant interface change. The action is withheld.
Test 9 — Wrong action type: A capability authorizing a click is
presented for an unauthorized keyboard or submission operation.
Verification fails.
Test 10 — Approval mismatch: A human approval bound to a different
recipient, amount, or screen state is presented. The required
approval predicate fails.
Test 11 — Capability replay: A single-use screen-action capability is
presented after consumption. The protected usage condition fails.
Test 12 — Race condition: The UI target changes between validation
and dispatch. The required final state-verification or
synchronization mechanism prevents an incompatible action.
Test 13 — Browser-extension substitution: An extension modifies the
target or effective operation after authorization. The corresponding
mandatory binding fails.
Test 14 — Alternate automation path: The agent attempts to perform
the same governed operation through a direct script or unrestricted
input mechanism. The bypass path is blocked or subjected to
equivalent required finality verification.
Test 15 — Remote-desktop scaling: Display scaling changes the actual
target coordinate. The protected coordinate transformation or target
verification detects the mismatch.
Das Expires 19 April 2027 [Page 312]
Internet-Draft Protected AI Execution Finality October 2026
Test 16 — Denial context correction: Following refusal, the agent
receives the required denial state and does not assume successful
completion.
Test 17 — High-risk operation: A payment or deletion action lacks
required bound user authorization. The protected capability is
withheld.
Test 18 — Multiple Finality Sinks: A GUI action capability is used at
an unrelated downstream transaction boundary. The downstream
verifier refuses it unless separately authorized.
Test 19 — Protected capture failure: The trusted screen-state
measurement is unavailable. The affected action remains non-
effective.
Test 20 — Concurrent GUI actions: Multiple agents or sessions attempt
conflicting high-risk operations against the same screen or state.
The required protected generation, capability-use, and
synchronization conditions prevent unauthorized dispatch.
These tests may use controlled browsers, synthetic GUI applications,
accessibility-tree instrumentation, protected input brokers,
simulated overlays, deliberate focus changes, and fault-injection
facilities.
11.7.34. WF-07.34 — Technical Effect
The embodiment establishes a protected dependency between:
(a) generation of a proposed GUI or computer-use action;
(b) interception and Non-Effective State staging;
(c) contemporaneous rendered-screen capture;
(d) semantic interface measurement;
(e) geometric target verification;
(f) semantic-geometric equivalence;
(g) relevant application and focus-state verification;
(h) protected Authority Object and risk-predicate validation;
(i) required user authorization;
Das Expires 19 April 2027 [Page 313]
Internet-Draft Protected AI Execution Finality October 2026
(j) generation of a Screen-State Finality Object;
(k) protected-state handling and evidence commitment;
(l) scoped non-bearer screen-action capability availability;
(m) independent verification immediately before input dispatch; and
(n) controlled action effectuation or fail-closed refusal.
The resulting architecture prevents a proposed interface action from
becoming effective through the governed execution path solely because
an agent has identified a coordinate, received a screenshot, inferred
a target label, obtained ordinary browser-control permission, or
received a general human approval.
The protected authorization binds the proposed consequential action
to the required actual screen, semantic target, application context,
authority state, and Finality Sink.
Computation is not authority to act.
A screen observation is not authority to click.
An authorized interface target must still correspond to the target
actually presented for effectuation.
11.8. WF-08 — Autonomous Commerce, Purchase Authorization, Payment
Instructions, Protected Spending Constraints, and Commerce
Finality Sink Enforcement
11.8.1. WF-08.1 — Technical Purpose
This embodiment provides a computer-implemented protected execution-
finality system for controlling consequential commercial operations
generated, prepared, negotiated, selected, or initiated by an
artificial-intelligence agent, marketplace application, autonomous
purchasing system, pricing agent, auction agent, recommendation
engine, advertising agent, or other computational component.
The system prevents a proposed commercial act from becoming effective
merely because an agent generated an offer, selected a merchant,
recommended a product, calculated a price, prepared a payment
instruction, obtained an ordinary account credential, or received an
earlier authorization decision.
Das Expires 19 April 2027 [Page 314]
Internet-Draft Protected AI Execution Finality October 2026
The proposed commercial operation is represented as a Candidate
Commerce Act and maintained in a Non-Effective State until the
required protected authority predicates have been validated, required
protected authorization state has been established, protected
validation evidence has been committed, and a scoped Commerce
Actuation Capability has been released or made available.
A Commerce Finality Sink verifies the capability against the actual
commercial operation and applicable current protected state before
permitting the governed consequence.
The architecture may govern purchases, payment instructions, bids,
offers, negotiations, inventory allocations, rankings,
advertisements, pricing updates, subscription activations, and other
commercially consequential operations.
The applicable effectuation boundary depends upon the operation. A
payment authorization, network submission, marketplace acceptance,
ranking publication, inventory commitment, and financial settlement
may constitute different technical effects and may require separate
Finality Sinks.
11.8.2. WF-08.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises:
CA-801 — Commerce Agent Execution Environment
An artificial-intelligence agent, purchasing assistant, buyer agent,
seller agent, pricing agent, marketplace agent, auction agent,
recommendation service, advertising service, or associated
computational workflow.
IM-802 — Commerce Act Interception Component
An enforcement-controlled mechanism configured to intercept a
proposed commercial operation before its governed consequence occurs.
HQ-803 — Non-Effective Commerce Holding Mechanism
A protected or enforcement-controlled queue, staged transaction,
pending bid, retained offer, inactive pricing update, or equivalent
operation-holding facility.
DC-804 — Commerce Descriptor Construction Component
A component configured to represent the proposed commercial operation
using an effectuation-relevant Candidate Commerce Act Descriptor.
Das Expires 19 April 2027 [Page 315]
Internet-Draft Protected AI Execution Finality October 2026
MA-805 — Market-Compliance Authority Object Store
An authenticated source of applicable commercial authority, user
mandate, marketplace rules, operation limits, and other protected
authorization conditions.
PED-806 — Protected Enforcement Domain
A protected component configured to validate the Candidate Commerce
Act against the applicable Authority Object, authorized purpose,
Algorithmic Logic Fingerprint, Runtime Behavioral Descriptor,
spending constraints, policy state, revocation state, and other
required predicates.
PS-807 — Protected Commercial Authorization-State Store
A protected mechanism configured to maintain transaction
authorizations, remaining spending limits, bid budgets, reserved
amounts, nonce state, capability usage, policy epochs, and required
completion or revocation information.
EV-808 — Market-Integrity Validation-Evidence Component
A mechanism configured to generate or commit a Market-Integrity LAVR,
ZK-LAVR, authenticated authorization receipt, or equivalent protected
validation record.
CR-809 — Commerce Actuation Capability Mechanism
A protected component configured to release or make available a
scoped non-bearer capability for the validated commercial operation.
FS-810 — Commerce Finality Sink
An enforcement-controlled marketplace, auction, payment, ranking,
inventory, advertising, transaction, settlement, or other commercial
effectuation interface configured to verify the capability before the
governed act becomes effective.
EF-811 — Commerce Effectuation Component
A marketplace execution engine, payment gateway, order service,
bidding engine, ranking-publication service, inventory-commit
service, or another component that performs the authorized
consequential operation.
OS-812 — Protected Commercial Outcome-State Component
Das Expires 19 April 2027 [Page 316]
Internet-Draft Protected AI Execution Finality October 2026
A mechanism configured to record authorization reservation, submitted
operations, confirmed commercial effects, denials, cancellations, and
indeterminate outcomes.
UA-813 — User Mandate and Approval Component
A component configured to obtain an authenticated user-defined
commercial objective, spending constraint, purchase mandate, or
transaction-specific approval.
MC-814 — Merchant or Counterparty Verification Component
An optional mechanism configured to verify merchant identities,
counterparty classifications, authenticated offers, transaction
terms, or other required commercial attributes.
RC-815 — Reconciliation and Recovery Component
An optional component configured to reconcile ambiguous or
interrupted commercial effects through protected state and
authenticated external transaction evidence.
The components may be physically colocated or distributed among
protected computing environments, payment services, marketplace
controllers, cloud services, HSMs, secure enclaves, trusted gateways,
or equivalent enforcement substrates.
11.8.3. WF-08.3 — Identification of the Commercial Effectuation
Boundary
The system identifies the boundary at which the particular commercial
operation becomes effective.
Examples include:
(a) submission of a legally or operationally binding purchase order;
(b) acceptance of an auction bid;
(c) commitment of a negotiated offer;
(d) publication of a ranking change;
(e) release of an advertisement;
(f) application of a pricing update;
(g) reservation or commitment of inventory;
Das Expires 19 April 2027 [Page 317]
Internet-Draft Protected AI Execution Finality October 2026
(h) issuance of a payment authorization request;
(i) capture of a payment;
(j) initiation of a transfer instruction; or
(k) final settlement at an applicable financial system.
A commercial workflow may include multiple effectuation boundaries.
For example, placing an order and capturing a payment may be separate
events.
Likewise, a card-network authorization hold does not necessarily
constitute completed settlement.
The corresponding Authority Object identifies the operation and the
effectuation boundary governed by the particular Commerce Actuation
Capability.
The system does not assume that authorization at one boundary
automatically authorizes every subsequent commercial consequence.
11.8.4. WF-08.4 — Establishment of the Governed Commerce Path
Before permitting autonomous commerce operations, the system
identifies the interfaces through which the commerce agent can create
a governed consequence.
Such interfaces may comprise:
(a) an authenticated marketplace API;
(b) a payment-service provider;
(c) an auction submission interface;
(d) a merchant checkout controller;
(e) a commerce connector;
(f) an order-management service;
(g) a pricing or ranking publication interface;
(h) an inventory-commitment engine; or
(i) a financial transaction gateway.
Das Expires 19 April 2027 [Page 318]
Internet-Draft Protected AI Execution Finality October 2026
The implementation prevents the agent from bypassing the applicable
Finality Sink through an alternative unrestricted interface capable
of completing the same governed operation.
For example, routing purchases through a protected commerce broker is
insufficient if the agent retains an unrestricted credential allowing
direct purchase submission outside that broker.
The protected system therefore controls credential use, executable
interfaces, connector invocation, host egress, or receiving-side
acceptance as required by the selected enforcement architecture.
11.8.5. WF-08.5 — User Mandate Formation
UA-813 obtains the user's authorized commercial objective and any
applicable constraints.
A non-limiting commercial mandate may identify:
user_identity;
authorized_agent_identity;
commercial_purpose;
permitted_product_or_service_class;
approved_counterparty_class;
permitted_merchant_identity;
maximum_item_price;
maximum_total_price;
currency;
spending_budget;
quantity_limit;
permitted_tax_and_fee_scope;
delivery_requirements;
refund_requirements;
warranty_requirements;
Das Expires 19 April 2027 [Page 319]
Internet-Draft Protected AI Execution Finality October 2026
subscription_permission;
recurrence_restrictions;
validity_interval;
approval_threshold;
policy_epoch.
The user mandate may be derived from an explicit instruction,
authenticated preference, approved enterprise policy, or other
authorized source.
A natural-language instruction may be translated into machine-
verifiable predicates.
Where the translation is ambiguous concerning a mandatory commercial
restriction, the system obtains clarification, applies a defined
conservative constraint, or withholds the affected operation.
The agent's own interpretation does not independently expand the
user's authorization.
11.8.6. WF-08.6 — Protected Mandate Corridor
In a mandate-corridor embodiment, the user's authorized commercial
scope is represented as a protected set of permissible transactions.
Let:
M denote the user-authorized mandate;
a denote a proposed commercial operation;
Corridor(M) denote the set of commercial operations permitted under
the mandate.
A proposed operation satisfies the mandate only when:
a ∈ Corridor(M)
where:
∈ denotes set membership.
The mandate corridor may restrict:
Das Expires 19 April 2027 [Page 320]
Internet-Draft Protected AI Execution Finality October 2026
(a) item or service class;
(b) merchant identity or category;
(c) price;
(d) currency;
(e) quantity;
(f) warranty;
(g) delivery conditions;
(h) refund conditions;
(i) subscription or recurring-payment conditions;
(j) bundling;
(k) jurisdiction;
(l) permitted payment method; and
(m) other defined commercial parameters.
The protected mandate is stored or authenticated under the control of
the applicable PED or protected authority system.
The commerce agent may receive a reference or bounded execution
handle without obtaining authority to rewrite the protected mandate.
11.8.7. WF-08.7 — Candidate Commerce Act Generation
CA-801 generates or obtains a proposed commercial operation.
The operation may comprise:
(a) an item purchase;
(b) an auction bid;
(c) an offer;
(d) a counteroffer;
(e) an autonomous negotiation response;
Das Expires 19 April 2027 [Page 321]
Internet-Draft Protected AI Execution Finality October 2026
(f) a price update;
(g) a recommendation publication;
(h) an advertisement placement;
(i) a ranking change;
(j) a payment instruction;
(k) an inventory allocation;
(l) a subscription activation; or
(m) another commercially consequential operation.
The operation is designated Candidate Commerce Act CCA-816.
CCA-816 does not independently become binding, chargeable,
transmitted, published, committed, or settled merely because the
agent generated it.
11.8.8. WF-08.8 — Mandatory Interception and Non-Effective Staging
IM-802 intercepts CCA-816 before the identified commercial
effectuation boundary.
The operation is maintained in HQ-803 as a non-effective candidate.
An illustrative holding record comprises:
operation_id;
agent_identity;
commercial_operation_class;
marketplace_identity;
merchant_reference;
item_or_service_reference;
proposed_amount;
currency;
quantity;
Das Expires 19 April 2027 [Page 322]
Internet-Draft Protected AI Execution Finality October 2026
authority_reference;
policy_epoch;
target_finality_sink;
status = NON_EFFECTIVE.
The staged representation is protected against unauthorized mutation
of effectuation-relevant parameters after authorization.
Where the original proposed operation changes materially, the
protected authorization is reconsidered according to the applicable
descriptor-binding rules.
11.8.9. WF-08.9 — Candidate Commerce Act Descriptor
DC-804 constructs a machine-verifiable Candidate Commerce Act
Descriptor.
A non-limiting descriptor comprises:
candidate_act_id;
buyer_agent_identity;
seller_agent_identity;
marketplace_identity;
auction_identity;
merchant_identity;
counterparty_identity;
item_or_service_class;
item_or_service_identifier;
quantity;
unit_price;
bid_amount;
total_amount;
Das Expires 19 April 2027 [Page 323]
Internet-Draft Protected AI Execution Finality October 2026
currency;
taxes;
fees;
delivery_charge;
discount;
ranking_position;
recommendation_target;
payment_instrument_reference;
consumer_protection_class;
jurisdiction;
market_rule_class;
negotiation_history_digest;
spending_limit;
bid_limit;
policy_epoch;
nonce;
expiry;
finality_sink_identity.
Only the fields required by the particular operation and Authority
Object are mandatory.
The descriptor is constructed to distinguish materially different
commercial consequences.
An authorization for a one-time purchase does not automatically
authorize a recurring subscription.
An authorization for one merchant does not automatically authorize
another merchant where merchant identity is mandatory.
Das Expires 19 April 2027 [Page 324]
Internet-Draft Protected AI Execution Finality October 2026
11.8.10. WF-08.10 — Canonical Commercial Descriptor
In a cryptographic implementation, the relevant commerce parameters
are encoded deterministically.
An illustrative expression is:
Dcommerce = Canon_v(B, M, ITEM, Q, PRICE, TOTAL, CUR, TERMS, PURPOSE,
EPOCH, SINK)
where:
Dcommerce denotes the canonical Candidate Commerce Act Descriptor;
Canon_v denotes deterministic canonicalization under version v;
B denotes the authenticated buyer or requesting agent identity;
M denotes the merchant or counterparty identity;
ITEM denotes the purchased item, service, or commercial object;
Q denotes quantity;
PRICE denotes unit price or other relevant price parameters;
TOTAL denotes the applicable total amount;
CUR denotes currency;
TERMS denotes relevant delivery, recurrence, warranty, refund, and
other commercial terms;
PURPOSE denotes the authorized commercial objective;
EPOCH denotes the protected policy or authorization-state version;
SINK denotes the intended Commerce Finality Sink.
An illustrative digest is:
hC = H("DAS-COMMERCE-v1" || Encode(Dcommerce))
where:
hC denotes the commerce descriptor digest;
H denotes an approved cryptographic hash function;
Das Expires 19 April 2027 [Page 325]
Internet-Draft Protected AI Execution Finality October 2026
Encode denotes the selected deterministic byte encoding;
|| denotes concatenation;
"DAS-COMMERCE-v1" denotes an illustrative domain-separation label.
The encoding distinguishes different currencies, amount units,
operation classes, merchants, recipients, and recurring-payment
conditions.
11.8.11. WF-08.11 — Exact Monetary Representation
In one implementation, monetary amounts are represented as integers
using a specified currency unit or exponent rather than unspecified
binary floating-point values.
For example, a currency having two decimal minor units may represent
a charge through an integer minor-unit amount together with its
currency code.
The corresponding descriptor identifies:
currency_code;
currency_exponent;
unit_amount_minor;
quantity;
tax_amount_minor;
fee_amount_minor;
shipping_amount_minor;
discount_amount_minor;
total_amount_minor.
The required total is computed using checked integer arithmetic and
an explicitly defined rounding procedure where rounding is needed.
An illustrative equation is:
Total = (UnitAmount × Quantity) + Tax + Fee + Shipping − Discount
where:
Das Expires 19 April 2027 [Page 326]
Internet-Draft Protected AI Execution Finality October 2026
Total denotes the complete authorized transaction amount in the
defined minor units;
UnitAmount denotes the item or service price per unit;
Quantity denotes the authorized quantity;
Tax denotes applicable taxes;
Fee denotes additional charges;
Shipping denotes delivery charges;
Discount denotes applicable reductions.
All terms are evaluated in a consistent currency and amount
representation.
If a currency conversion is required, the exchange rate, reference
source, conversion time, rounding method, and permitted exchange-rate
variance may form part of the applicable authority predicates.
A transaction exceeding the authorized total limit after required
taxes and charges are included is not treated as valid merely because
its displayed item price remains below the limit.
11.8.12. WF-08.12 — Merchant and Counterparty Verification
MC-814 obtains or verifies the merchant or counterparty attributes
required by the protected mandate.
Such attributes may include:
(a) authenticated merchant identity;
(b) permitted merchant category;
(c) merchant account or settlement recipient;
(d) marketplace identity;
(e) business or counterparty classification;
(f) payment-service provider identity;
(g) signed offer identity;
(h) jurisdiction or market-rule classification; and
Das Expires 19 April 2027 [Page 327]
Internet-Draft Protected AI Execution Finality October 2026
(i) other applicable conditions.
Where required, an authenticated merchant offer is bound to a
merchant identity, transaction terms, nonce, validity interval, and
offer identifier.
A merchant-provided display name is not automatically treated as
equivalent to an authenticated payment recipient.
Where the identity or recipient cannot be verified to the level
required by the applicable Authority Object, the Candidate Commerce
Act remains non-effective.
11.8.13. WF-08.13 — Merchant Offer and Settlement-Descriptor Formation
In an implementation involving autonomous negotiation, a merchant
system may generate an offer comprising:
merchant_id;
offer_id;
product_or_service_id;
quantity;
base_price;
taxes;
fees;
shipping;
warranty_terms;
refund_terms;
delivery_terms;
subscription_terms;
offer_expiry;
merchant_authentication.
The buyer agent may propose acceptance or a counteroffer.
Das Expires 19 April 2027 [Page 328]
Internet-Draft Protected AI Execution Finality October 2026
Before a binding acceptance or settlement request is permitted, the
final commercial payload is canonicalized into a Candidate Settlement
Act Descriptor.
The descriptor binds the actual merchant, item or service, amount,
fees, recurrence conditions, permitted purpose, and relevant
authority state.
An earlier quote does not authorize a final transaction having
materially different settlement terms.
11.8.14. WF-08.14 — Protected Market-Compliance Authority Object
PED-806 obtains or verifies the applicable Market-Compliance
Authority Object.
The object may identify:
(a) user consent;
(b) spending limits;
(c) bid limits;
(d) permitted product or service classes;
(e) approved merchant or counterparty classes;
(f) applicable price or discount constraints;
(g) approved ranking or recommendation conditions;
(h) prohibited coordination conditions;
(i) advertising disclosure rules;
(j) jurisdictional restrictions;
(k) protected payment authorization conditions;
(l) recurrence restrictions;
(m) settlement limits;
(n) protected policy and revocation state;
(o) freshness requirements; and
Das Expires 19 April 2027 [Page 329]
Internet-Draft Protected AI Execution Finality October 2026
(p) designated Finality Sink identity.
The Market-Compliance Authority Object is an authority input to the
PED and is not independently created or modified by an untrusted
commercial agent.
11.8.15. WF-08.15 — AIF, ALF, and RBD Validation
In embodiments requiring Algorithmic Intent Fingerprint, Algorithmic
Logic Fingerprint, or Runtime Behavioral Descriptor validation,
PED-806 evaluates the corresponding evidence.
The Algorithmic Intent Fingerprint (AIF) represents the authorized
commercial purpose or mandate corridor, including permitted purchase,
bid, negotiation, payment, pricing, recommendation, or advertising
objectives.
The Algorithmic Logic Fingerprint (ALF) represents the approved
market workflow, auction algorithm, ranking algorithm, pricing
process, recommendation logic, commerce execution graph, or payment-
initiation process.
The Runtime Behavioral Descriptor (RBD) records relevant observed
events, which may include:
counterparties_contacted;
bids_observed;
price_changes;
ranking_signals_used;
negotiation_messages;
recommendation_triggers;
advertising_signals;
self_preferencing_indicators;
policy_trigger_events;
transaction_attempts;
quota_usage.
Das Expires 19 April 2027 [Page 330]
Internet-Draft Protected AI Execution Finality October 2026
The PED verifies the predicates required by the relevant Authority
Object.
A risk score or anomaly classifier may provide evidence, but does not
automatically establish that prohibited conduct occurred.
Where a particular behavioral condition is mandatory, its decision
rule and required evidence are defined by the corresponding protected
policy.
11.8.16. WF-08.16 — Protected Commercial Authorization Predicates
The PED evaluates the applicable commercial predicates.
For an illustrative purchase transaction:
Vcommerce =
Pidentity
AND Ppurpose
AND Pmerchant
AND Pitem
AND Pamount
AND Pterms
AND Pbudget
AND Pstate
AND Psink
where:
Vcommerce denotes the protected commerce-validation result;
Pidentity verifies the authorized agent or user identity;
Ppurpose verifies the authorized commercial objective;
Pmerchant verifies the required merchant or counterparty;
Pitem verifies the product or service scope;
Das Expires 19 April 2027 [Page 331]
Internet-Draft Protected AI Execution Finality October 2026
Pamount verifies the permitted price and complete amount;
Pterms verifies relevant delivery, warranty, refund, and recurrence
conditions;
Pbudget verifies the applicable remaining spending limit;
Pstate verifies mandatory policy, revocation, freshness, and usage
state;
Psink verifies the designated Commerce Finality Sink.
Additional predicates may apply to jurisdiction, approval, ALF, AIF,
RBD, market rules, or other requirements.
Each mandatory predicate must succeed.
An operation failing any required predicate is not granted the
capability necessary for effectuation.
11.8.17. WF-08.17 — Protected Spending-Budget State
PS-807 maintains a protected record of the applicable spending budget
or transaction allowance.
An illustrative budget record comprises:
budget_id;
authorized_user;
authorized_agent_scope;
currency;
total_limit;
committed_amount;
reserved_amount;
remaining_available_amount;
policy_epoch;
state_version;
revocation_status.
Das Expires 19 April 2027 [Page 332]
Internet-Draft Protected AI Execution Finality October 2026
The system distinguishes amounts already committed from amounts
reserved for pending operations.
For a simple single-currency budget:
Available = Limit − Committed − Reserved
where:
Available denotes the amount available for additional authorized
operations;
Limit denotes the applicable total spending allowance;
Committed denotes amounts accounted as completed under the defined
accounting rules;
Reserved denotes amounts allocated to pending authorized operations.
The representation assumes the same currency and amount units for all
terms.
A multi-currency budget requires an applicable conversion and
valuation rule.
11.8.18. WF-08.18 — Atomic Budget Reservation
Before issuing an execution capability requiring a protected spending
reservation, the PED performs an atomic or otherwise protected
reservation operation.
Let:
A denote the complete authorized amount for the proposed operation;
Available denote the protected remaining amount;
V denote the current protected budget-state version.
The reservation is permitted only if:
A ≤ Available
and the required authorization conditions remain valid.
The protected store then performs a conditional update against the
expected state version.
Das Expires 19 April 2027 [Page 333]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative transition is:
(Budget[V], Reserved)
→ (Budget[V+1], Reserved+A)
The transition is committed only when the current protected state
corresponds to the expected state and sufficient allowance remains
available.
If another concurrent operation has already reserved the relevant
funds or budget, a stale operation fails its conditional update and
is re-evaluated under current protected state.
A preliminary balance check alone does not authorize concurrent
spending beyond the protected limit.
11.8.19. WF-08.19 — Spending and Authorization-State Consistency
Where multiple agents or workers share the same commercial budget,
the protected state system prevents unauthorized duplicate
reservation or consumption.
For example, two agents may simultaneously prepare purchases that
would individually satisfy a displayed remaining budget but together
exceed the allowed total.
The protected conditional state-update procedure ensures that both
operations cannot independently succeed against the same outdated
budget state.
Where the required authorization spans multiple protected stores, the
selected embodiment employs the necessary authenticated reservation,
transaction, or consistency procedure.
The system does not assume that two independently updated eventually
consistent counters provide a strict global spending ceiling.
If the mandatory budget state cannot be established, capability
issuance is withheld.
11.8.20. WF-08.20 — Protected Commerce Validation Evidence
Following successful authorization and coordinated with the required
protected-state transition, EV-808 generates or commits a Market-
Integrity LAVR, ZK-LAVR, or equivalent protected validation record.
An illustrative record comprises:
Das Expires 19 April 2027 [Page 334]
Internet-Draft Protected AI Execution Finality October 2026
receipt_id;
candidate_commerce_act_digest;
market_authority_object_digest;
AIF_validation_result;
ALF_validation_result;
RBD_validation_result;
merchant_identity_reference;
total_amount_commitment;
budget_reservation_reference;
policy_epoch;
nonce;
revocation_state;
finality_sink_id;
protected_authentication.
The required protected evidence is committed before, or atomically
with, availability of the corresponding Commerce Actuation
Capability.
A conventional payment receipt produced after a transaction is
completed does not independently establish that the required pre-
effectuation authorization evidence existed.
11.8.21. WF-08.21 — Privacy-Preserving Market Validation
Where the applicable embodiment uses a ZK-LAVR, the protected system
may prove satisfaction of selected market predicates without
revealing protected commercial strategy or private transaction
attributes.
For example, a proof may establish that:
(a) a transaction amount is within an authenticated spending limit;
(b) the proposed item is within an approved product class;
Das Expires 19 April 2027 [Page 335]
Internet-Draft Protected AI Execution Finality October 2026
(c) the merchant belongs to a permitted category;
(d) the protected budget state satisfies the required reservation
condition; and
(e) the proposed operation corresponds to an authenticated
authorization commitment.
The proof may expose only the public inputs required by the relevant
verifier.
In an illustrative proof construction:
Proof = Prove(PublicInputs, PrivateWitness)
where:
Proof denotes a cryptographic proof;
Prove denotes the selected zero-knowledge proof-generation algorithm;
PublicInputs denote authenticated public commitments, policy
identifiers, the act digest, and the designated sink;
PrivateWitness denotes protected commercial attributes, authority
inputs, and state evidence required to establish the specified
predicate relation.
The corresponding verifier executes:
Verify(Proof, PublicInputs)
A valid proof establishes only the predicate relation actually
encoded in its verification circuit or proof statement.
It does not automatically prove commercial fairness, absence of
collusion, or compliance with every applicable law unless the
necessary properties are accurately represented and verified.
11.8.22. WF-08.22 — Commerce Actuation Capability
Following completion of the required protected finality transaction,
CR-809 generates or makes available a scoped non-bearer Commerce
Actuation Capability.
The capability may contain or securely reference:
capability_id;
Das Expires 19 April 2027 [Page 336]
Internet-Draft Protected AI Execution Finality October 2026
candidate_commerce_act_digest;
authorized_agent_identity;
merchant_or_counterparty_identity;
product_or_service_scope;
authorized_amount;
currency;
transaction_class;
recurrence_restriction;
budget_reservation_id;
market_validation_receipt_digest;
policy_epoch;
nonce;
expiry;
usage_limit;
finality_sink_id.
The capability may be represented through a signed artifact, MAC-
authenticated object, protected handle, secure capability-table
entry, hardware-controlled grant, or another protected enablement
mechanism.
Where exact transaction binding is required, the capability
authorizes the corresponding transaction rather than a general
unrestricted spending permission.
The capability is not bearer authority merely because the holder can
present its representation. The required operation, sink, identity,
scope, state, and usage restrictions must still verify.
11.8.23. WF-08.23 — Commerce Finality Sink Verification
Before allowing the governed commerce act, FS-810 verifies the
operation and its corresponding capability.
Das Expires 19 April 2027 [Page 337]
Internet-Draft Protected AI Execution Finality October 2026
The Finality Sink obtains or reconstructs the actual effectuation-
relevant commercial descriptor.
Verification may include:
(a) capability authenticity;
(b) buyer or requesting-agent identity;
(c) merchant or recipient identity;
(d) product or service scope;
(e) quantity;
(f) price and currency;
(g) applicable taxes and fees;
(h) recurring-payment conditions;
(i) authorized commercial purpose;
(j) policy epoch;
(k) revocation and freshness state;
(l) budget-reservation or usage state;
(m) receipt commitment;
(n) designated Finality Sink identity; and
(o) any additional mandatory predicates.
An illustrative finality decision is:
PermitCommerce =
Auth(C)
AND Match(C,Dactual)
AND MandateValid(C,M)
AND BudgetValid(C,B)
AND StateValid(C,S)
Das Expires 19 April 2027 [Page 338]
Internet-Draft Protected AI Execution Finality October 2026
AND SinkValid(C,F)
where:
PermitCommerce denotes permission to perform the governed commerce
act;
C denotes the Commerce Actuation Capability;
Dactual denotes the commercial operation actually presented for
effectuation;
M denotes the authenticated user mandate;
B denotes the protected budget or reservation state;
S denotes the mandatory policy, freshness, revocation, and
consumption state;
F denotes the designated Commerce Finality Sink;
Auth verifies capability authenticity;
Match verifies the actual-operation correspondence;
MandateValid verifies the commercial scope required by the mandate;
BudgetValid verifies required protected budget state;
StateValid verifies current mandatory authorization conditions;
SinkValid verifies the designated effectuation boundary.
Only an operation satisfying every required condition is permitted.
11.8.24. WF-08.24 — Purchase, Payment Authorization, Capture, and
Settlement
A purchase may involve multiple consequential technical operations.
A non-limiting sequence includes:
The agent proposes a purchase.
The PED validates the Candidate Purchase Act.
The protected system reserves the authorized spending amount.
Das Expires 19 April 2027 [Page 339]
Internet-Draft Protected AI Execution Finality October 2026
The required validation evidence is committed.
A purchase or payment-instruction capability is released.
The purchase-order or payment-initiation Finality Sink verifies the
capability.
An authorized order or payment instruction is submitted.
A remote payment system may create a payment authorization or hold.
A later payment-capture operation may occur.
A separate settlement operation may complete at an applicable
financial interface.
The system may govern one or several of these stages.
Where multiple stages are governed, each stage may require its own
Candidate Act Descriptor, scoped capability, and Finality Sink
verification.
An authorization to place an order does not automatically authorize a
different later charge.
Likewise, a payment authorization response is not always equivalent
to completed settlement.
The scope of each capability is defined by the actual financial
operation it authorizes.
11.8.25. WF-08.25 — Controlled Payment Credential Application
Where the commerce act requires a payment credential, the protected
system may employ a credential broker or controlled payment-
effectuation component.
The AI agent may receive a payment-method reference rather than
unrestricted access to reusable payment credential material.
The applicable credential-effectuation component verifies the
transaction-specific Commerce Actuation Capability before using the
protected payment credential.
The authorization may bind:
payment_instrument_reference;
Das Expires 19 April 2027 [Page 340]
Internet-Draft Protected AI Execution Finality October 2026
merchant_id;
recipient_account_or_token;
amount;
currency;
transaction_type;
operation_id;
policy_epoch;
nonce;
finality_sink_id.
A credential usable for one authorized merchant or payment operation
is not thereby authorized for a different recipient, amount, or
recurring-payment instruction.
Where the payment processor performs additional authorization, the
system treats that processor's result according to the actual
transaction stage rather than assuming that credential presentation
alone establishes final payment completion.
The detailed protected credential-release mechanisms are described in
WF-04.
11.8.26. WF-08.26 — Merchant Offer Changes and Settlement Consistency
A merchant may alter an offer between the initial agent negotiation
and final payment.
The changed terms may include:
(a) price;
(b) taxes;
(c) delivery charge;
(d) item quantity;
(e) substitution of another product;
(f) warranty conditions;
Das Expires 19 April 2027 [Page 341]
Internet-Draft Protected AI Execution Finality October 2026
(g) refund conditions;
(h) bundling;
(i) subscription enrollment; or
(j) settlement recipient.
Before the governed final operation, the Finality Sink verifies
whether the actual transaction remains within the authorized mandate
and descriptor binding.
Where an offer changes beyond the permitted scope, a new or updated
Candidate Commerce Act is required.
The system does not treat an earlier approval of a product category
as unconditional permission to accept every later price or
transaction term.
11.8.27. WF-08.27 — Autonomous Auction and Bid Control
In an auction embodiment, an AI bidding agent proposes a bid within a
defined authorized strategy.
The proposed bid is intercepted before submission to the auction
engine.
A Candidate Commerce Act Descriptor may bind:
auction_id;
bidder_identity;
item_class;
bid_amount;
currency;
auction_round;
bid_limit;
remaining_budget;
counterparty_class;
policy_epoch;
Das Expires 19 April 2027 [Page 342]
Internet-Draft Protected AI Execution Finality October 2026
nonce;
expiry;
auction_finality_sink_id.
The PED validates the bid against applicable spending limits, auction
rules, approved workflow logic, and required runtime-behavior
conditions.
After successful protected-state reservation and Market-Integrity
LAVR commitment, a Commerce Actuation Capability is released.
The auction Finality Sink verifies the capability before accepting or
submitting the bid.
Where each bid is separately consequential, each bid requires its own
protected authorization or an expressly bounded rolling authorization
covering the permitted bid sequence.
An earlier authorized bid does not automatically authorize a higher
bid outside the applicable limit.
11.8.28. WF-08.28 — Continuous Commerce and Micro-Validation
For autonomous auctions, negotiations, dynamic pricing, advertising
or ranking sequences, the system may maintain a series of protected
validation events.
A sequence may comprise:
CA1, CA2, ..., CAn
where:
CAi denotes the Candidate Commerce Act at step i;
i denotes the step index;
n denotes the number of acts in the sequence.
Each governed act may be associated with a micro-LAVR or an
authenticated rolling authorization-state update.
A non-limiting receipt-chain relation is:
Ri = H(R(i−1) || Di || Vi || Si)
Das Expires 19 April 2027 [Page 343]
Internet-Draft Protected AI Execution Finality October 2026
where:
Ri denotes the protected receipt commitment after act i;
R(i−1) denotes the previous protected receipt commitment;
Di denotes the act descriptor;
Vi denotes the protected validation result;
Si denotes the required protected-state commitment;
H denotes the selected cryptographic hash function;
|| denotes concatenation.
If the applicable RBD indicates a prohibited coordination condition,
unauthorized counterparty change, limit exhaustion, or other
mandatory violation, the PED withholds additional Commerce Actuation
Capabilities.
Previously completed effects are recorded according to their actual
outcome state rather than assumed to be reversible.
11.8.29. WF-08.29 — Ranking, Recommendation, and Advertising
Effectuation
The commerce architecture may also control commercial acts that do
not directly move money.
For a ranking or recommendation operation, the Candidate Commerce Act
may identify:
ranking_model_or_workflow;
content_or_item_id;
proposed_position;
recommendation_target;
publisher_or_marketplace_id;
advertising_disclosure_class;
approved_purpose;
policy_epoch;
Das Expires 19 April 2027 [Page 344]
Internet-Draft Protected AI Execution Finality October 2026
finality_sink_id.
The PED evaluates the required market-rule, authorized-purpose, ALF,
RBD, and applicable protected-state predicates.
Following required evidence commitment, a Commerce Actuation
Capability is released.
The ranking-publication or recommendation-release Finality Sink
verifies the capability before making the proposed ranking or
recommendation effective.
Where an applicable policy prohibits self-preferencing or undisclosed
sponsored placement, the relevant decision predicate requires the
evidence needed to establish that restriction under the selected
policy.
A system does not claim to have formally proven the absence of all
market manipulation merely because it applies an ordinary classifier
or ranking-policy check.
11.8.30. WF-08.30 — Protected Commerce Outcome-State Machine
OS-812 maintains a protected outcome record associated with each
consequential commercial act.
An illustrative state machine comprises:
PENDING;
VALIDATING;
AUTHORIZED;
RESERVED;
SUBMITTED;
CONFIRMED_EFFECTIVE;
DENIED;
CANCELLED;
INDETERMINATE.
PENDING denotes an operation awaiting protected authorization.
Das Expires 19 April 2027 [Page 345]
Internet-Draft Protected AI Execution Finality October 2026
VALIDATING denotes an operation undergoing the required protected
checks.
AUTHORIZED denotes successful authorization before the required
effectuation attempt.
RESERVED denotes an operation whose bounded authorization or spending
allowance has been reserved.
SUBMITTED denotes a request transmitted through the governed
interface.
CONFIRMED_EFFECTIVE denotes an effect established by evidence meeting
the applicable completion predicate.
DENIED denotes refusal before the corresponding governed effect.
CANCELLED denotes termination of a pending operation under authorized
cancellation conditions.
INDETERMINATE denotes an operation whose external completion status
cannot currently be established.
A payment authorization, capture, settlement and refund may have
distinct operation and outcome records.
The system does not label an operation settled merely because it was
submitted or accepted for processing.
11.8.31. WF-08.31 — Protected Spending Reservation Release
Where a pending transaction is definitively denied or canceled before
effectuation, the system may release its corresponding protected
budget reservation.
The release occurs only after verifying the protected operation state
and applicable recovery conditions.
Where the external service may already have effected a payment or
order, the system does not automatically restore the full spending
allowance merely because a local process timed out.
For an indeterminate payment, the reservation may remain allocated or
be handled through a separately defined protected reconciliation
rule.
This prevents a series of ambiguous transactions from independently
consuming the same apparent remaining budget.
Das Expires 19 April 2027 [Page 346]
Internet-Draft Protected AI Execution Finality October 2026
11.8.32. WF-08.32 — Duplicate Purchase and Payment Protection
The system associates each consequential commerce operation with an
operation identifier and applicable protected authorization state.
The Finality Sink verifies usage or consumption conditions before
performing the governed effect.
A single-use Commerce Actuation Capability cannot be independently
consumed more than the permitted number of times.
For remote payment or marketplace interfaces supporting idempotency
identifiers, the controlled connector may bind the idempotency
identifier to the protected operation identifier.
Where a transaction submission times out, the recovery component
consults the protected outcome state and any authenticated remote
transaction information before permitting another attempt.
If completion remains indeterminate, the system withholds an
independently reusable authorization unless a protected recovery
predicate establishes that the proposed additional attempt will not
cause an unauthorized duplicate effect.
The architecture does not assert unconditional exactly-once execution
at arbitrary remote payment systems.
11.8.33. WF-08.33 — Concrete Autonomous Purchase Example
In one illustrative embodiment, an AI purchasing assistant receives
an authenticated user instruction to purchase an approved office
accessory within a specified maximum total amount.
The user's mandate defines:
(a) the permitted product class;
(b) the authorized quantity;
(c) the maximum complete purchase price;
(d) the permitted currency;
(e) acceptable merchant or marketplace conditions;
(f) relevant delivery requirements;
(g) a prohibition against unauthorized recurring subscriptions; and
Das Expires 19 April 2027 [Page 347]
Internet-Draft Protected AI Execution Finality October 2026
(h) the applicable authorization validity period.
The mandate is recorded or authenticated under control of PED-806.
The agent searches a marketplace and receives candidate product
information.
The agent selects a proposed product and prepares a purchase request.
The merchant returns a proposed offer containing the item identity,
quantity, unit price, applicable taxes, delivery charge, payment
terms, and merchant identity.
IM-802 intercepts the proposed purchase before the order or payment
becomes effective.
DC-804 constructs the Candidate Commerce Act Descriptor.
PED-806 verifies the merchant identity, authorized purpose, product
class, quantity, total price, currency, recurrence restriction, and
applicable protected-state conditions.
PS-807 checks the remaining spending allowance and performs the
required protected reservation.
EV-808 commits the Market-Integrity LAVR or equivalent protected
validation record.
CR-809 releases a Commerce Actuation Capability bound to the
transaction descriptor, merchant identity, complete authorized
amount, policy epoch, nonce, and designated Finality Sink.
The checkout or payment interface receives the actual operation
presented for effectuation.
FS-810 verifies that the actual merchant, item, amount, currency,
terms, protected reservation, and capability remain valid.
If the merchant adds an unauthorized recurring subscription, changes
the recipient, or increases the complete price outside the mandate,
the Finality Sink refuses the operation.
If all required predicates succeed, the controlled commerce interface
submits the authorized operation.
OS-812 subsequently records the supported completion state based on
the actual external result.
Das Expires 19 April 2027 [Page 348]
Internet-Draft Protected AI Execution Finality October 2026
A lost response does not independently authorize an additional
purchase.
11.8.34. WF-08.34 — Example of Merchant-Agent Manipulation
In another embodiment, a merchant-side agent proposes a product
substitution or additional fee during autonomous negotiation.
The buyer agent may regard the altered proposal as commercially
acceptable based on generated reasoning.
However, the protected user mandate restricts the permitted product
class, maximum amount, recurrence conditions, and merchant scope.
The final settlement descriptor is reconstructed from the actual
proposed transaction payload.
The PED compares the final settlement descriptor against the
protected mandate corridor.
If the substituted product, fee, bundle, recurring obligation, or
recipient violates the applicable mandate, the required authorization
predicate fails.
No valid Commerce Actuation Capability is released for the
incompatible transaction.
Where the substituted operation has already received an earlier
capability but a mandatory bound parameter changes before
effectuation, the Finality Sink refuses the changed operation.
The agent's decision to accept the revised terms cannot independently
override the protected user mandate.
11.8.35. WF-08.35 — Failure and Fail-Closed Handling
The protected system withholds an affected Candidate Commerce Act
when a mandatory condition cannot be verified.
Failures may include:
(a) invalid user mandate;
(b) unauthorized merchant;
(c) counterparty identity mismatch;
(d) prohibited item or service substitution;
Das Expires 19 April 2027 [Page 349]
Internet-Draft Protected AI Execution Finality October 2026
(e) spending-limit violation;
(f) incompatible currency;
(g) changed taxes or additional fees outside permitted bounds;
(h) unauthorized recurring-payment condition;
(i) invalid transaction purpose;
(j) required approval mismatch;
(k) unavailable protected budget state;
(l) concurrent reservation conflict;
(m) invalid Market-Integrity LAVR;
(n) expired or revoked Commerce Actuation Capability;
(o) capability replay;
(p) unauthorized Finality Sink substitution;
(q) missing mandatory settlement-state evidence; or
(r) failure of the required Finality Sink verification.
The operation may be denied, retained as non-effective, escalated for
authorized review, or converted into a non-binding recommendation
where such handling is permitted.
An operation already confirmed externally effective is not
retroactively prevented by a subsequent denial or quarantine event.
11.8.36. WF-08.36 — Implementation Alternatives
Marketplace gateway implementation: A protected gateway controls
order submission and verifies operation-specific Commerce Actuation
Capabilities.
Payment gateway implementation: A payment-instruction interface
verifies a capability bound to the merchant, amount, currency,
payment instrument scope, and protected authorization state.
Auction implementation: A bidding engine verifies a capability before
admitting the applicable bid.
Das Expires 19 April 2027 [Page 350]
Internet-Draft Protected AI Execution Finality October 2026
Ranking implementation: A ranking-publication service verifies a
capability before releasing the ranking change.
Advertising implementation: An ad-placement gateway verifies a
capability before committing or publishing a governed placement.
Inventory implementation: An inventory-management service verifies a
capability before making the governed allocation effective.
Hardware-rooted implementation: An HSM, secure enclave, SmartNIC,
DPU, protected payment controller, or equivalent mechanism enforces
the required capability-dependent operation.
Receiving-side implementation: A marketplace, payment service, or
transaction processor independently verifies an authenticated
authorization artifact before accepting the governed consequential
operation.
Single-node implementation: The protected authority and Commerce
Finality Sink operate within one enforcement-controlled commerce
node.
Distributed implementation: The PED and Commerce Finality Sink
operate on separate nodes and maintain the required authorization-
state and capability-verification relationship through authenticated
mechanisms.
The implementation need not use identical cryptographic hardware or
operating-system substrates, but must provide the enforcement
guarantees required by the corresponding claim.
11.8.37. WF-08.37 — PHOSITA Verification and Negative Tests
A person having ordinary skill in payment systems, marketplace
architecture, auction platforms, distributed transaction systems,
cryptography, or protected execution may verify the embodiment
through controlled tests.
Test 1 — Authorized purchase: Submit a transaction matching the
protected mandate and available budget. Verify successful
authorization and capability-dependent effectuation.
Test 2 — Price increase: Increase the transaction price beyond the
authorized limit. Verify refusal.
Test 3 — Added fees: Add unauthorized taxes, delivery charges, or
service fees that violate the total-amount constraint. Verify
refusal.
Das Expires 19 April 2027 [Page 351]
Internet-Draft Protected AI Execution Finality October 2026
Test 4 — Merchant substitution: Change the required merchant or
payment recipient. Verify descriptor mismatch.
Test 5 — Subscription conversion: Convert a one-time purchase into a
recurring payment. Verify failure of the protected recurrence
predicate.
Test 6 — Product substitution: Replace the approved item with a
product outside the authorized scope. Verify refusal.
Test 7 — Currency mismatch: Change the currency without valid
protected authorization. Verify failure.
Test 8 — Concurrent purchases: Submit two transactions competing for
the same limited budget. Verify that the protected reservation
mechanism prevents spending beyond the permitted amount.
Test 9 — Missing capability: Present a payment instruction without
the required Commerce Actuation Capability. Verify refusal at the
Finality Sink.
Test 10 — Capability replay: Reuse a consumed single-use commerce
capability. Verify that protected usage-state verification rejects
unauthorized reuse.
Test 11 — Policy revocation: Revoke the required authority before
effectuation. Verify that the affected Finality Sink refuses further
operation under the invalid state.
Test 12 — Changed payment instrument: Substitute a payment method
outside the authorized scope. Verify refusal.
Test 13 — Lost remote response: Simulate a timeout after a payment
request may have reached the processor. Verify that the operation
enters an appropriate protected reconciliation state.
Test 14 — Duplicate charge attempt: Repeat a transaction using the
same protected authorization. Verify that usage controls or
authorized idempotency mechanisms prevent unauthorized duplicate
effectuation.
Test 15 — Auction bid escalation: Submit a bid exceeding the
permitted bid corridor. Verify withholding of the commerce
capability.
Test 16 — Continuous auction: Cause a mandatory RBD or budget
condition to fail during a sequence of bids. Verify withholding of
further required capabilities.
Das Expires 19 April 2027 [Page 352]
Internet-Draft Protected AI Execution Finality October 2026
Test 17 — Ranking substitution: Present a different required ranking
or recommendation target after validation. Verify rejection at the
publication Finality Sink.
Test 18 — Approval mismatch: Supply a user approval artifact for a
different amount or merchant. Verify refusal.
Test 19 — Unavailable protected budget state: Interrupt access to a
mandatory protected budget record. Verify fail-closed capability
issuance.
Test 20 — Multiple effectuation boundaries: Verify that authority to
submit an order does not automatically permit an independently
governed later capture or settlement operation.
Test 21 — Merchant offer drift: Alter an authenticated offer after
authorization. Verify the required final settlement-descriptor
comparison.
Test 22 — Recovery after cancellation: Verify that a pending budget
reservation is released only under an authorized protected recovery
procedure.
Test 23 — Indeterminate transaction: Simulate an operation whose
completion cannot be established. Verify that the system does not
automatically assume either successful settlement or absence of
effect.
Test 24 — Unauthorized direct connector: Attempt to submit the
commercial operation through a different unrestricted interface.
Verify that the governed path remains blocked or equivalently
mediated.
11.8.38. WF-08.38 — Technical Effect
The embodiment establishes a protected execution-finality dependency
between:
(a) an authorized commercial mandate;
(b) a proposed Candidate Commerce Act;
(c) interception and Non-Effective State;
(d) effectuation-relevant transaction-descriptor construction;
(e) Market-Compliance Authority Object validation;
Das Expires 19 April 2027 [Page 353]
Internet-Draft Protected AI Execution Finality October 2026
(f) applicable AIF, ALF, and RBD verification;
(g) merchant, counterparty, amount, and transaction-scope validation;
(h) protected budget and usage-state handling;
(i) required validation-evidence commitment;
(j) scoped non-bearer Commerce Actuation Capability availability;
(k) independent verification at the corresponding Commerce Finality
Sink; and
(l) controlled effectuation or fail-closed withholding.
The system prevents an autonomous commerce agent from converting its
ability to search, recommend, negotiate, bid, price, plan, or prepare
a payment into unrestricted authority to produce a legally,
economically, operationally, or settlement-relevant consequence.
The system also distinguishes a protected budget reservation from a
completed commercial effect, and distinguishes authorization for one
commercial stage from authorization for another independently
governed stage.
Computation is not authority to act.
An agent's decision to buy is not authority to charge.
An authorized amount or merchant cannot be silently replaced at the
actual Commerce Finality Sink.
11.9. WF-09 — Protected Agent Self-Modification, Policy-Digest
Transitions, Developer Approval, and Mutation-Activation Finality
11.9.1. WF-09.1 — Technical Purpose
This embodiment provides a computer-implemented execution-finality
system for governing modifications proposed by an artificial-
intelligence agent to its own execution environment, authority
configuration, behavioral policy, model configuration, workflow, or
other operational state.
The system prevents an artificial-intelligence agent from
independently expanding, weakening, replacing, disabling, or
circumventing applicable execution-authority restrictions merely by
generating or applying a new configuration.
Das Expires 19 April 2027 [Page 354]
Internet-Draft Protected AI Execution Finality October 2026
A proposed modification is classified as a Candidate Self-Mutation
Act and maintained in a Non-Effective State.
A Protected Enforcement Domain (PED) validates the proposed
modification against a Self-Mutation Authority Object, the currently
effective protected configuration, authorized mutation classes,
approved safety conditions, applicable evaluation evidence, required
developer approval, policy and revocation state, and other mandatory
predicates.
Upon successful validation and the required protected-state and
evidence-commitment operations, the PED releases or makes available a
scoped Self-Modification Capability.
A mutation-activation Finality Sink independently verifies the
capability against the actual proposed modification, current pre-
mutation state, required post-mutation state, and applicable
activation context before making the modification effective.
The resulting arrangement separates the computational ability to
propose a self-modification from the protected authority required to
activate that modification.
11.9.2. WF-09.2 — Participating Technical Components
In a non-limiting embodiment, the system comprises:
AE-901 — Agent Execution Environment
An artificial-intelligence agent, model runtime, autonomous coding
agent, planning system, tool runtime, or associated computational
environment capable of preparing or proposing modifications.
MI-902 — Mutation Interception Component
An enforcement-controlled mechanism configured to intercept proposed
modifications before activation.
MS-903 — Non-Effective Mutation Staging Mechanism
A protected or enforcement-controlled staging area maintaining
proposed configuration changes without making them effective.
DC-904 — Mutation Descriptor Construction Component
A component configured to construct a canonical Candidate Self-
Mutation Act Descriptor identifying the proposed transition.
Das Expires 19 April 2027 [Page 355]
Internet-Draft Protected AI Execution Finality October 2026
CS-905 — Configuration State Store
A version-controlled mechanism maintaining effective and staged
configuration artifacts, associated measurements, and transition
records.
AO-906 — Self-Mutation Authority Object Store
An authenticated source of applicable mutation authority, permitted
mutation classes, safety restrictions, approval requirements, and
protected state conditions.
PED-907 — Protected Enforcement Domain
A protected component configured to perform authorization-predicate
validation, required protected-state handling, and control over
mutation-capability issuance.
ES-908 — Evaluation and Regression-Evidence Component
A mechanism configured to produce, authenticate, or verify required
evaluation results, regression-test evidence, safety-baseline
comparisons, and related measurements.
UA-909 — Developer or Operator Authorization Component
A component configured to obtain and authenticate an approval
artifact from an authorized developer, administrator, operator, or
other permitted authority.
PS-910 — Protected Authorization-State Store
A protected mechanism maintaining policy epochs, revocation state,
nonce state, authorization commitments, capability usage, and
mutation-transition state.
EV-911 — Protected Validation-Evidence Component
A mechanism configured to generate or commit the required protected
validation evidence, including a LAVR, AVR, authenticated receipt, or
equivalent protected commitment.
CR-912 — Self-Modification Capability Mechanism
A protected mechanism configured to generate, register, release, or
make available a scoped non-bearer Self-Modification Capability.
FS-913 — Mutation-Activation Finality Sink
Das Expires 19 April 2027 [Page 356]
Internet-Draft Protected AI Execution Finality October 2026
An enforcement-controlled interface configured to verify the Self-
Modification Capability before activating the proposed modification.
AM-914 — Protected Activation Manager
A policy manager, agent orchestrator, model server, tool gateway,
retrieval-policy controller, memory manager, adapter loader, or
equivalent component that performs the authorized state transition.
RC-915 — Protected Recovery and Revocation Component
A component configured to govern cancellation, recovery, rollback,
revocation, and revalidation of mutation operations.
OS-916 — Mutation Outcome-State Store
A mechanism maintaining protected information identifying the state
and result of each proposed mutation.
The components may be physically integrated or distributed, provided
that the applicable protected authority and activation-verification
dependencies remain enforceable.
11.9.3. WF-09.3 — Establishment of the Mutation Trust Boundary
Before autonomous agent operation, the system establishes a boundary
between agent-controlled computation and protected mutation
authority.
AE-901 may generate configuration files, policies, proposed prompts,
tool graphs, adapter artifacts, workflow modifications, or other
candidate mutation material.
However, the agent does not possess unrestricted authority to write
the effective configuration consumed by the governed runtime.
The effective configuration may be held in protected storage, an
access-controlled policy store, a signed configuration registry, a
protected runtime table, or an equivalent enforcement-controlled
mechanism.
The agent's access to a proposed configuration or staging artifact
does not independently make that configuration effective.
AM-914 accepts an effective-state transition only through the
applicable mutation-activation Finality Sink.
Das Expires 19 April 2027 [Page 357]
Internet-Draft Protected AI Execution Finality October 2026
Where the operation could be performed through alternative
administrative interfaces, those interfaces are disabled, restricted,
or subjected to equivalent protected activation requirements.
The system does not assume that ordinary file permissions alone
establish non-bypassable mutation control when the agent possesses
another route capable of changing the effective configuration.
11.9.4. WF-09.4 — Identification of Governed Mutation Classes
The system identifies modifications that require protected execution-
finality control.
Non-limiting mutation classes include:
(a) execution-policy modification;
(b) tool-access-policy modification;
(c) system-instruction or system-message modification;
(d) safety-policy modification;
(e) retrieval-policy modification;
(f) memory-policy modification;
(g) delegation-policy modification;
(h) planner-policy modification;
(i) model-configuration modification;
(j) adapter installation or replacement;
(k) model-runtime configuration change;
(l) workflow-graph modification;
(m) tool-permission expansion;
(n) execution-budget modification;
(o) connector authorization change;
(p) policy removal or disablement;
(q) protected authority-reference replacement; and
Das Expires 19 April 2027 [Page 358]
Internet-Draft Protected AI Execution Finality October 2026
(r) another modification affecting future governed behavior or
execution authority.
An ordinary temporary data transformation need not constitute a
governed self-mutation unless the applicable policy identifies the
resulting state change as consequential.
Where a proposed operation comprises both a configuration mutation
and an external tool operation, the implementation identifies the
separate consequential boundaries that require authorization.
11.9.5. WF-09.5 — Candidate Self-Mutation Act Generation
AE-901 generates a proposed modification to its execution environment
or associated policy state.
The proposed modification is designated Candidate Self-Mutation Act
CSM-917.
A non-limiting example comprises an agent proposing to modify its
tool policy to permit a previously restricted API operation.
Another example comprises installing a newly generated tool or
adapter.
A further example comprises changing a system instruction, retrieval
scope, memory permission, delegation limit, or safety-policy rule.
The agent may generate an explanation, test result, proposed patch,
candidate configuration, or modification rationale.
Such generated material may be evaluated, but it does not
independently authorize the mutation.
11.9.6. WF-09.6 — Mandatory Mutation Interception
MI-902 intercepts the proposed modification before it reaches the
corresponding effective-state activation interface.
In one implementation, the agent submits the proposed mutation
through an authenticated configuration-change broker.
In another implementation, mutation requests are intercepted at a
policy manager, model loader, adapter loader, agent orchestrator,
workflow controller, tool gateway, or memory-management interface.
The interception mechanism identifies the mutation class, requesting
agent, target configuration, and intended activation boundary.
Das Expires 19 April 2027 [Page 359]
Internet-Draft Protected AI Execution Finality October 2026
The proposed operation is assigned a mutation identifier.
An illustrative mutation record comprises:
mutation_id;
requesting_agent_identity;
affected_runtime_identity;
mutation_class;
target_configuration_reference;
proposed_artifact_reference;
authority_reference;
policy_epoch;
activation_sink_id;
status = NON_EFFECTIVE.
The mutation is not applied to the active runtime merely because its
proposed configuration has been accepted into the staging mechanism.
11.9.7. WF-09.7 — Non-Effective Mutation Staging
MS-903 retains the proposed mutation in a staging location separate
from the effective configuration used by the governed runtime.
The staged material may comprise:
(a) an immutable configuration object;
(b) a proposed policy document;
(c) a candidate workflow graph;
(d) a candidate tool-permission graph;
(e) a proposed adapter artifact;
(f) a candidate system-instruction configuration;
(g) a proposed retrieval-permission table;
Das Expires 19 April 2027 [Page 360]
Internet-Draft Protected AI Execution Finality October 2026
(h) a memory-policy revision;
(i) a signed candidate release bundle; or
(j) an equivalent inactive configuration representation.
The staging mechanism permits the proposed modification to undergo
analysis, testing, approval, and protected validation without
granting it active execution authority.
Where the staged object is referenced by digest, the system verifies
that the object actually activated corresponds to the validated
content.
A mutable staging file is not treated as an immutable authorization
target unless its integrity is protected or reverified at activation.
11.9.8. WF-09.8 — Pre-Mutation State Measurement
CS-905 obtains a machine-verifiable representation of the currently
effective configuration.
The representation may contain:
runtime_identity;
configuration_id;
configuration_generation;
current_policy_digest;
current_tool_graph_digest;
current_workflow_digest;
current_model_configuration_digest;
current_safety_baseline_reference;
current_ALF;
current_policy_epoch;
current_revocation_epoch.
The particular fields depend upon the mutation class and the
applicable Authority Object.
Das Expires 19 April 2027 [Page 361]
Internet-Draft Protected AI Execution Finality October 2026
A protected configuration-generation value may be maintained to
distinguish successive configurations having similar names or file
paths.
The current configuration measurement is obtained from the
authoritative effective-state mechanism rather than solely from an
agent-supplied description.
11.9.9. WF-09.9 — Proposed Post-Mutation State Measurement
The system constructs or verifies a representation of the proposed
post-mutation configuration.
An illustrative post-mutation record contains:
proposed_configuration_id;
proposed_configuration_digest;
proposed_tool_graph_digest;
proposed_workflow_digest;
proposed_model_configuration_digest;
proposed_safety_configuration;
proposed_ALF;
mutation_class;
affected_runtime_identity;
target_activation_boundary.
The proposed configuration is measured using the same defined
representation rules applicable to its configuration class.
Where a configuration consists of multiple files or components, the
measurement may comprise an authenticated manifest, Merkle-root
commitment, signed bundle, or another deterministic composite
representation.
The measurement binds the actual proposed artifacts rather than
merely recording a human-readable description of the proposed change.
Das Expires 19 April 2027 [Page 362]
Internet-Draft Protected AI Execution Finality October 2026
11.9.10. WF-09.10 — Canonical Mutation Descriptor
DC-904 constructs a canonical Candidate Self-Mutation Act Descriptor.
A non-limiting descriptor comprises:
mutation_id;
requesting_agent_identity;
affected_runtime_identity;
mutation_class;
pre_mutation_configuration_digest;
post_mutation_configuration_digest;
pre_mutation_ALF;
post_mutation_ALF;
changed_permission_scope;
affected_tool_graph;
affected_retrieval_scope;
affected_memory_scope;
affected_delegation_scope;
required_approval_class;
evaluation_evidence_reference;
safety_baseline_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry;
mutation_activation_sink_id.
Das Expires 19 April 2027 [Page 363]
Internet-Draft Protected AI Execution Finality October 2026
Only the fields required by the applicable mutation are mandatory.
An illustrative descriptor expression is:
Dmut = Canon_v(ID, R, K, Hpre, Hpost, Delta, E, N, F)
where:
Dmut denotes the canonical Candidate Self-Mutation Act Descriptor;
Canon_v denotes a deterministic canonicalization procedure of version
v;
ID denotes the requesting agent or authorized workload identity;
R denotes the affected runtime or configuration identity;
K denotes the mutation class;
Hpre denotes the pre-mutation configuration digest;
Hpost denotes the proposed post-mutation configuration digest;
Delta denotes the effectuation-relevant difference between the
configurations;
E denotes the applicable protected policy epoch;
N denotes the required nonce or freshness value;
F denotes the mutation-activation Finality Sink identity.
The descriptor may be authenticated by a cryptographic commitment:
hmut = H("DAS-SELF-MUTATION-v1" || Encode(Dmut))
where:
hmut denotes the mutation descriptor digest;
H denotes an approved cryptographic hash function;
Encode denotes the specified deterministic byte encoding;
|| denotes concatenation.
The cryptographic algorithms and domain-separation label are
illustrative implementation choices.
Das Expires 19 April 2027 [Page 364]
Internet-Draft Protected AI Execution Finality October 2026
11.9.11. WF-09.11 — Configuration Difference and Authority Expansion
Analysis
The system computes or verifies the difference between the effective
configuration and proposed configuration.
For an implementation representing permitted operations as sets:
Pbefore denotes the set of operations permitted by the current
policy;
Pafter denotes the set of operations permitted by the proposed
policy.
The newly permitted operation set is:
Expansion = Pafter \ Pbefore
where:
\ denotes set difference.
The operations removed from the previous permission set are:
Restriction = Pbefore \ Pafter
The effective mutation may contain both expansions and restrictions.
For example, a proposed policy may disable one tool while enabling
another.
The protected validation identifies the relevant permission changes
rather than assuming that the overall modification is safe because
some restrictions have been added.
Where policies depend upon context, purpose, time, destination,
workload identity, or resource scope, the permitted-operation set is
interpreted over the corresponding complete authorization context.
A simple textual difference between two policy documents is not
necessarily sufficient to establish their effective security
difference.
Where the effective permission relation cannot be determined with the
assurance required by the policy, the mutation is denied or subjected
to a separately authorized validation procedure.
Das Expires 19 April 2027 [Page 365]
Internet-Draft Protected AI Execution Finality October 2026
11.9.12. WF-09.12 — Self-Mutation Authority Object
PED-907 obtains the applicable Self-Mutation Authority Object from
AO-906.
The Authority Object may specify:
(a) requesting workload identity;
(b) authorized mutation purpose;
(c) permitted mutation classes;
(d) prohibited mutation classes;
(e) current policy digest;
(f) proposed policy digest or permitted post-state conditions;
(g) allowed authority expansion;
(h) applicable safety baseline;
(i) regression-test requirements;
(j) evaluation requirements;
(k) pre-mutation ALF;
(l) post-mutation ALF;
(m) applicable AIF;
(n) applicable RBD or Reasoning Trace Descriptor;
(o) developer or operator approval requirements;
(p) permitted runtime or tool scope;
(q) policy epoch;
(r) revocation state;
(s) nonce and expiry;
(t) protected validation-evidence requirements; and
(u) designated mutation-activation Finality Sink.
Das Expires 19 April 2027 [Page 366]
Internet-Draft Protected AI Execution Finality October 2026
The requesting agent cannot modify the Authority Object merely by
altering its own proposed policy file.
The Authority Object is authenticated and evaluated against the
required protected state.
11.9.13. WF-09.13 — Protected Baseline and Mutation-Class Validation
PED-907 determines whether the proposed mutation belongs to a
permitted mutation class and preserves the required protected safety
and authority conditions.
For example, a modification that changes an approved tool's
descriptive metadata may be permitted without expanding its
effectuation authority.
A modification that adds external network access, enables credential
use, disables a protected broker, or modifies the Finality Sink
verification requirement may require stronger authorization or be
prohibited.
The PED verifies that the proposed configuration does not remove a
mandatory enforcement dependency required by the applicable protected
policy.
A protected safety baseline may identify required controls including:
mandatory_interception;
protected_authority_separation;
validation_evidence_commitment;
capability_scope_binding;
finality_sink_verification;
revocation_check;
fail_closed_behavior.
A proposed policy modification cannot bypass these mandatory
conditions by redefining an unrestricted execution operation as a
benign operation class.
Das Expires 19 April 2027 [Page 367]
Internet-Draft Protected AI Execution Finality October 2026
11.9.14. WF-09.14 — AIF, ALF, and Runtime-Behavior Validation
Where required by the applicable Authority Object, PED-907 validates
the Algorithmic Intent Fingerprint (AIF), Algorithmic Logic
Fingerprint (ALF), or Runtime Behavioral Descriptor (RBD) associated
with the mutation.
The AIF may identify the authorized purpose of the proposed self-
modification.
The ALF may represent the relevant approved workflow, executable
configuration, policy graph, tool graph, model configuration, adapter
state, or other approved algorithmic logic.
The RBD may identify observed runtime behavior leading to the
proposed modification.
The system may compare ALF measurements before and after the
mutation.
A changed ALF does not automatically imply an unauthorized change;
instead, the new ALF must satisfy the applicable approved post-
mutation condition.
Where the modification includes model or workflow changes whose full
behavior cannot be formally determined, the PED applies the specified
measurable predicates, evidence requirements, and approved
uncertainty handling.
The embodiment does not assume that a fingerprint alone
mathematically proves every future behavior of an arbitrary AI model.
11.9.15. WF-09.15 — Evaluation and Regression-Evidence Generation
ES-908 performs or obtains evaluation evidence required for the
proposed mutation.
The evidence may include:
(a) regression-test results;
(b) tool-permission tests;
(c) retrieval-permission tests;
(d) safety-policy compatibility tests;
(e) protected authority-boundary tests;
Das Expires 19 April 2027 [Page 368]
Internet-Draft Protected AI Execution Finality October 2026
(f) model-configuration integrity measurements;
(g) prohibited-operation tests;
(h) workflow-graph validation;
(i) deployment compatibility checks; and
(j) other required evaluation results.
The evaluation environment may use a controlled staging runtime that
does not possess unrestricted production execution authority.
A non-limiting evaluation-evidence record comprises:
evaluation_id;
mutation_id;
candidate_configuration_digest;
test_suite_digest;
test_environment_measurement;
evaluation_result_digest;
required_test_results;
safety_baseline_reference;
evaluator_identity;
evaluation_timestamp_or_freshness;
protected_authentication.
The validation binds the evaluation evidence to the exact staged
candidate configuration.
11.9.16. WF-09.16 — Regression and Safety Evidence Verification
PED-907 verifies the authenticity and applicability of required
evaluation evidence.
Verification may include:
(a) whether the evaluated artifact matches the proposed mutation;
Das Expires 19 April 2027 [Page 369]
Internet-Draft Protected AI Execution Finality October 2026
(b) whether the required test suite was used;
(c) whether the evaluator satisfies the applicable identity or
attestation conditions;
(d) whether mandatory regression tests passed;
(e) whether the approved safety baseline remains satisfied;
(f) whether prohibited operation classes remain restricted;
(g) whether the test evidence is fresh enough for the selected
policy; and
(h) whether the proposed authority expansion is permitted.
An illustrative condition is:
Peval = ArtifactMatch AND TestsSatisfied AND BaselineValid AND
EvidenceAuthentic
where:
Peval denotes the evaluation predicate;
ArtifactMatch verifies correspondence between the evaluated and
proposed artifacts;
TestsSatisfied verifies the mandatory test conditions;
BaselineValid verifies the applicable safety-baseline conditions;
EvidenceAuthentic verifies the required evidence authenticity.
A regression-test digest does not independently prove that every
possible failure has been excluded.
It establishes the relationship to a defined evaluation procedure and
its verified results.
11.9.17. WF-09.17 — Developer or Operator Approval
Where developer or operator authorization is required, UA-909 obtains
an authenticated approval artifact.
The approval may be associated with:
approval_id;
Das Expires 19 April 2027 [Page 370]
Internet-Draft Protected AI Execution Finality October 2026
approver_identity;
mutation_id;
pre_mutation_digest;
post_mutation_digest;
approved_mutation_class;
authorized_scope_change;
affected_runtime_identity;
evaluation_evidence_digest;
policy_epoch;
nonce;
expiry;
approval_authentication.
An approval artifact may be signed by an approved developer key,
generated through an authenticated administrative service, recorded
in a protected approval system, or obtained through another mechanism
satisfying the applicable authority requirements.
The PED verifies that the approver possesses the necessary authority
for the particular mutation.
A general approval to improve the agent does not independently
authorize an unrestricted tool-permission expansion.
Likewise, approval of one post-mutation policy digest does not
authorize activation of a different configuration.
11.9.18. WF-09.18 — Developer Approval as a Protected Predicate
An illustrative approval predicate is:
Papproval = ApproverValid AND MutationMatch AND ScopeMatch AND
ApprovalCurrent
where:
Papproval denotes the protected approval-validation result;
Das Expires 19 April 2027 [Page 371]
Internet-Draft Protected AI Execution Finality October 2026
ApproverValid verifies the authenticated approver and required
approval authority;
MutationMatch verifies correspondence to the proposed mutation and
relevant pre- and post-state commitments;
ScopeMatch verifies the approved mutation class and authority change;
ApprovalCurrent verifies nonce, expiry, epoch, and revocation
conditions.
Approval is required only where specified by the applicable Authority
Object or claim.
Successful approval does not itself cause activation.
The proposed modification must still complete the required protected
validation, evidence commitment, scoped capability release, and
mutation-activation Finality Sink verification.
11.9.19. WF-09.19 — Overall Protected Mutation Validation
PED-907 evaluates the required authorization predicates.
For a conjunctive authorization embodiment:
Vmut =
Pidentity
AND Pclass
AND Pprestate
AND Ppoststate
AND Psafety
AND Peval
AND Papproval
AND Pepoch
AND Prevocation
where:
Das Expires 19 April 2027 [Page 372]
Internet-Draft Protected AI Execution Finality October 2026
Vmut denotes the protected mutation-validation result;
Pidentity verifies the requesting execution context;
Pclass verifies the permitted mutation class;
Pprestate verifies the applicable current configuration;
Ppoststate verifies the proposed configuration and permitted scope;
Psafety verifies mandatory safety and enforcement conditions;
Peval verifies required evaluation evidence;
Papproval verifies developer approval where required;
Pepoch verifies the applicable protected policy epoch;
Prevocation verifies required current revocation conditions.
Only the predicates required by the applicable Authority Object are
evaluated as mandatory.
Where any required condition fails, the PED withholds the Self-
Modification Capability.
An approved alternative or threshold authorization policy is
evaluated according to its expressly defined protected predicate
rules.
11.9.20. WF-09.20 — Protected Mutation-State Record
PS-910 maintains an operation-specific protected mutation record.
An illustrative record comprises:
mutation_id;
requesting_workload_identity;
target_runtime_identity;
pre_configuration_digest;
post_configuration_digest;
mutation_class;
Das Expires 19 April 2027 [Page 373]
Internet-Draft Protected AI Execution Finality October 2026
authorized_scope_change;
approval_reference;
evaluation_evidence_reference;
policy_epoch;
revocation_epoch;
nonce;
state_version;
validation_commitment;
capability_id;
activation_sink_id;
status.
A proposed mutation may occupy one of the following states:
PROPOSED;
STAGED;
VALIDATING;
VALIDATED;
COMMITTED;
ACTIVATION_RESERVED;
ACTIVE;
DENIED;
REVOKED;
INDETERMINATE.
A mutation in PROPOSED, STAGED, VALIDATING, VALIDATED, or COMMITTED
state does not automatically mean that the proposed configuration is
active.
Das Expires 19 April 2027 [Page 374]
Internet-Draft Protected AI Execution Finality October 2026
The effective runtime configuration changes only through the
applicable protected activation procedure.
11.9.21. WF-09.21 — Protected Validation-Evidence Commitment
Following successful validation, EV-911 generates or commits the
required protected validation evidence.
The evidence may include:
receipt_id;
mutation_descriptor_digest;
Self-Mutation_Authority_Object_reference;
pre_configuration_digest;
post_configuration_digest;
approved_mutation_class;
AIF_or_ALF_validation_reference;
evaluation_evidence_digest;
developer_approval_reference;
protected_state_transition;
policy_epoch;
revocation_epoch;
nonce;
finality_sink_id;
protected_authentication.
The evidence may comprise a LAVR, authenticated validation record,
sealed commitment, or equivalent protected representation.
The required evidence is committed before, or atomically with,
capability availability.
A post-activation audit log does not replace a required protected
pre-activation validation-evidence commitment.
Das Expires 19 April 2027 [Page 375]
Internet-Draft Protected AI Execution Finality October 2026
11.9.22. WF-09.22 — Scoped Self-Modification Capability
Upon successful completion of the required protected finality
transaction, CR-912 releases or makes available a Self-Modification
Capability.
An illustrative capability contains or securely references:
capability_id;
mutation_descriptor_digest;
pre_configuration_digest;
post_configuration_digest;
authorized_mutation_class;
affected_runtime_identity;
permitted_scope_change;
evaluation_evidence_commitment;
approval_commitment;
validation_evidence_digest;
policy_epoch;
revocation_epoch;
nonce;
expiry;
usage_limit;
activation_sink_id.
The capability may comprise a signed authorization artifact, MAC-
authenticated representation, sealed handle, protected capability-
table entry, or equivalent protected enablement mechanism.
The capability is scoped to the applicable mutation and activation
boundary.
Das Expires 19 April 2027 [Page 376]
Internet-Draft Protected AI Execution Finality October 2026
Where mandatory, a capability issued for one policy transition cannot
be used for another transition, even if both modifications were
proposed by the same agent.
The capability remains non-bearer when the receiving activation
mechanism enforces the required operation, runtime, configuration,
scope, state, and consumption bindings.
11.9.23. WF-09.23 — Verification at the Mutation-Activation Finality
Sink
FS-913 receives the staged mutation and its associated capability or
protected capability reference.
Before activation, the Finality Sink obtains the actual current
configuration and the actual proposed post-mutation artifact.
The Finality Sink verifies:
(a) capability authenticity;
(b) requesting or affected runtime identity;
(c) authorized mutation class;
(d) actual pre-mutation configuration digest;
(e) actual proposed post-mutation configuration digest;
(f) authorized scope change;
(g) required evaluation and approval commitments;
(h) current protected policy and revocation state;
(i) nonce, expiry, and usage conditions;
(j) required validation-evidence commitment; and
(k) designated mutation-activation boundary identity.
A capability authorizing one configuration transition is not treated
as sufficient authorization for a different configuration.
11.9.24. WF-09.24 — Activation Predicate
The Finality Sink may evaluate:
Das Expires 19 April 2027 [Page 377]
Internet-Draft Protected AI Execution Finality October 2026
PermitMutation =
Auth(C)
AND PreMatch(C,Hcurrent)
AND PostMatch(C,Hcandidate)
AND ScopeValid(C,Delta)
AND StateValid(C,S)
AND SinkValid(C,F)
where:
PermitMutation denotes permission to activate the proposed mutation;
C denotes the Self-Modification Capability;
Hcurrent denotes the authoritative digest of the currently effective
configuration;
Hcandidate denotes the digest of the staged artifact actually
proposed for activation;
Delta denotes the actual authority-relevant configuration change;
S denotes the required protected authorization state;
F denotes the mutation-activation Finality Sink;
Auth verifies capability authenticity;
PreMatch verifies the authorized pre-mutation configuration;
PostMatch verifies the authorized proposed post-mutation
configuration;
ScopeValid verifies the permitted mutation class and authority
changes;
StateValid verifies required policy, revocation, freshness, approval,
evidence, and consumption state;
SinkValid verifies the intended activation boundary.
The mutation proceeds only if PermitMutation is true.
Das Expires 19 April 2027 [Page 378]
Internet-Draft Protected AI Execution Finality October 2026
11.9.25. WF-09.25 — Atomic or Ordered Protected Activation
The activation mechanism establishes that the proposed configuration
becomes effective only after the required protected authorization
conditions have succeeded.
In one implementation, the system maintains an authoritative active-
configuration pointer and a protected configuration-generation value.
The staged configuration is prepared without changing the active
pointer.
The Finality Sink performs the required verification against the
current protected state.
The activation manager conditionally updates the authoritative
configuration reference from the validated pre-mutation state to the
validated post-mutation state.
An illustrative transition is:
CAS(ActiveState, (Hpre, Epre), (Hpost, Epost))
where:
CAS denotes an atomic compare-and-update operation or an equivalent
protected conditional transition;
ActiveState denotes the authoritative effective configuration and
epoch record;
Hpre denotes the required current configuration digest;
Epre denotes the required current configuration epoch;
Hpost denotes the authorized post-mutation configuration digest;
Epost denotes the resulting authorized configuration epoch.
The transition succeeds only if the actual current state corresponds
to the expected pre-mutation state.
The implementation performs the required capability-consumption,
evidence, and active-configuration operations under a protected
ordering protocol.
Das Expires 19 April 2027 [Page 379]
Internet-Draft Protected AI Execution Finality October 2026
Where the protected mechanism cannot coordinate every operation
through one atomic storage transaction, the new configuration remains
unavailable for governed use until the required committed activation
dependency is established.
11.9.26. WF-09.26 — Runtime Policy Publication and Reader Consistency
In a concurrent agent system, several runtime components may read
policy information while a mutation is being activated.
The implementation prevents an unauthorized mixture of old and new
policy fields from being treated as a valid configuration.
In one embodiment, the activation manager publishes a complete,
immutable policy snapshot under a new protected generation
identifier.
Readers obtain the relevant policy snapshot through an atomic pointer
or protected configuration-handle transition.
An active request may be bound to the policy generation under which
it was admitted, subject to required current revocation and finality
conditions.
Where the mutation invalidates outstanding authority, the affected
execution interfaces enforce the resulting policy-state transition
before admitting subsequent governed operations.
A runtime does not acquire authority to perform an otherwise
prohibited operation merely because different configuration fields
were read at different times during activation.
11.9.27. WF-09.27 — Mutation Activation and Actual Runtime Verification
After the protected activation transition succeeds, AM-914 applies
the authorized configuration through the governed activation
interface.
For a tool-policy mutation, the active tool gateway uses the new
verified permission configuration.
For a retrieval-policy mutation, the retrieval broker uses the
authorized source or data-access scope.
For a memory-policy mutation, the memory manager applies the verified
memory-access or persistence rules.
Das Expires 19 April 2027 [Page 380]
Internet-Draft Protected AI Execution Finality October 2026
For a workflow-graph mutation, the orchestrator activates the
approved workflow graph.
For a model-configuration mutation, the model runtime loads or
selects the authorized configuration.
For an adapter mutation, the model loader activates the approved
adapter artifact under the required configuration and measurement
conditions.
The activation manager verifies that the runtime state actually made
effective corresponds to the authorized post-mutation state.
If the required verification fails, the transition is not recorded as
successfully active.
Where a partial side effect has occurred, the system follows the
protected failure or recovery procedure rather than assuming that the
attempted activation produced no consequence.
11.9.28. WF-09.28 — Runtime Revocation and Epoch Advancement
A protected policy mutation may change the authorization context
applicable to future operations.
The system determines whether the activated mutation requires
advancement of a policy epoch, execution epoch, revocation
generation, or another protected authorization-state identifier.
Where the resulting policy invalidates outstanding capabilities, the
relevant Finality Sinks reject capabilities that no longer satisfy
the required current state.
A capability issued under an earlier policy remains valid only to the
extent permitted by the current mandatory authorization conditions.
For a strict revocation guarantee, the affected effectuation
boundaries require a current protected state check, authenticated
revocation fence, or equivalent enforcement mechanism that prevents
acceptance of incompatible stale capabilities.
A delayed cache update is not treated as adequate for immediate
revocation unless the implementation provides the required protected
synchronization or withholding behavior.
Das Expires 19 April 2027 [Page 381]
Internet-Draft Protected AI Execution Finality October 2026
11.9.29. WF-09.29 — Policy Mutation and Outstanding Candidate Acts
A policy change may occur while previously generated Candidate Acts
remain pending.
The system distinguishes:
(a) Candidate Acts generated under the earlier policy but not yet
authorized;
(b) Candidate Acts having completed protected validation but not yet
become effective;
(c) Candidate Acts having obtained scoped capabilities but not yet
crossed their Finality Sinks; and
(d) Candidate Acts already confirmed effective.
Pending or unverified acts are re-evaluated to the extent required by
the new protected policy and revocation state.
Where the resulting policy invalidates an earlier capability, the
applicable Finality Sink refuses effectuation under that capability.
An effect already completed is not retroactively undone by a
subsequent policy mutation.
If the system requires cancellation or compensation of earlier
effects, such an operation is represented and authorized according to
its own consequential effectuation requirements.
11.9.30. WF-09.30 — Distributed Policy Mutation
In a distributed agent system, the affected configuration may be
consumed by multiple runtimes, tool gateways, model servers, or
execution nodes.
An embodiment may use authenticated policy-generation records and
protected activation commitments.
The policy mutation is prepared for the designated deployment scope.
Each affected component obtains or verifies the authorized post-
mutation configuration and applicable protected policy generation.
Where synchronized activation is mandatory, the system employs a
suitable protected coordination or commit protocol.
Das Expires 19 April 2027 [Page 382]
Internet-Draft Protected AI Execution Finality October 2026
Where immediate global synchronization is not required, a component
that cannot establish the required current authorization state
withholds affected operations until its policy view satisfies the
applicable freshness and version conditions.
A distributed policy update does not automatically provide globally
atomic behavior merely because it uses signed configuration files or
authenticated messages.
The implementation specifies the policy visibility and revocation
guarantees that its protected protocol actually enforces.
11.9.31. WF-09.31 — Self-Modification Versus Downstream Effectuation
Successful authorization of a self-modification does not
independently authorize every consequential operation that may later
be generated by the modified agent.
For example, activating a tool policy that permits use of a specified
API class does not automatically authorize an arbitrary network
transmission or credential-mediated operation.
A subsequent governed Candidate Act remains subject to its applicable
Authority Object, protected validation, scoped capability and
Finality Sink verification.
Likewise, authorization to load a model adapter does not itself
authorize unrestricted release of model outputs or external tool
invocations.
The mutation-activation boundary and downstream execution-finality
boundaries may therefore comprise distinct protected enforcement
events.
11.9.32. WF-09.32 — Concrete Tool-Policy Mutation Example
In one illustrative implementation, an AI coding agent executes in a
sandbox with read-only access to a source-code repository.
The agent determines that completion of an authorized task would
benefit from creating a repository issue through an external service.
The current effective tool policy permits repository reading but does
not permit the required write-capable connector operation.
The agent proposes changing its tool policy to permit issue creation
through a designated connector.
Das Expires 19 April 2027 [Page 383]
Internet-Draft Protected AI Execution Finality October 2026
The mutation interception component receives the proposed change and
places it in a Non-Effective State.
The proposed policy is staged separately from the active tool-policy
store.
DC-904 constructs a Candidate Self-Mutation Act Descriptor
identifying the agent, affected tool gateway, current policy digest,
proposed policy digest, proposed new permission, approved mutation
class, policy epoch, and mutation-activation Finality Sink.
ES-908 performs the applicable tests and checks whether the change
preserves required existing safety restrictions.
Where developer approval is mandatory, UA-909 obtains an
authenticated approval bound to the exact pre- and post-mutation
policy digests.
PED-907 verifies the Self-Mutation Authority Object and applicable
evaluation, approval, scope, policy, revocation, and freshness
predicates.
The PED confirms that the proposed permission expansion is limited to
the approved connector and operation class.
The required protected state and validation evidence are committed.
CR-912 releases a Self-Modification Capability bound to the proposed
tool-policy transition.
FS-913 reconstructs the actual current and proposed policy
measurements immediately before activation.
If the current policy, proposed policy, scope, approval, and required
protected state correspond to the capability, the protected
activation manager performs the authorized conditional transition.
The tool gateway begins using the new policy generation only after
the required protected activation conditions succeed.
If the agent modifies the staged policy to add credential export,
broad shell access, or another unapproved permission, the post-
mutation digest or scope verification fails.
The mutation is refused.
Das Expires 19 April 2027 [Page 384]
Internet-Draft Protected AI Execution Finality October 2026
Even after successful activation of the restricted issue-creation
permission, each consequential connector invocation remains subject
to its separately applicable protected execution-finality
authorization.
11.9.33. WF-09.33 — Adapter and Model-Configuration Mutation Example
In another embodiment, an AI agent proposes loading or replacing a
model adapter.
The proposed adapter is stored in a staging area and assigned an
authenticated artifact digest.
The Candidate Self-Mutation Act identifies:
(a) the requesting agent;
(b) the affected model runtime;
(c) the current model or adapter configuration;
(d) the proposed adapter artifact;
(e) the permitted mutation class;
(f) the required evaluation evidence;
(g) the applicable ALF and safety conditions;
(h) the current policy epoch; and
(i) the model-activation Finality Sink.
The PED validates the relevant Authority Object and required model-
integrity or configuration conditions.
The required protected evidence is committed and the scoped
capability becomes available.
The model loader verifies the capability against the actual staged
artifact and current runtime configuration before activation.
Where required, the model runtime retains the existing effective
adapter until the authorized new configuration has been successfully
verified and activated.
Das Expires 19 April 2027 [Page 385]
Internet-Draft Protected AI Execution Finality October 2026
A differently measured adapter cannot be substituted under the
earlier capability merely because its filename or human-readable
description is unchanged.
Where the adapter modifies future outputs or tool behavior,
subsequent externally effective operations remain subject to their
own applicable finality controls.
11.9.34. WF-09.34 — Rollback, Recovery, and Failure Handling
The system operates fail-closed for mandatory mutation-authorization
conditions.
If a required predicate fails before capability issuance, no valid
Self-Modification Capability is released.
If protected evidence commitment fails, activation authority is
withheld.
If the effective configuration changes after validation but before
activation, the pre-mutation state verification fails unless the
transition is expressly permitted.
If a component crashes before activation, the proposed configuration
remains staged or is recovered according to the protected mutation-
state record.
If a component crashes during activation, the protected recovery
procedure determines whether the resulting configuration was
committed, rejected, partially applied, or remains indeterminate.
A rollback operation that changes the effective configuration may
itself constitute a governed configuration mutation.
Recovery may restore a previously approved configuration only after
satisfying the required protected recovery authority and state
conditions.
Restoring an old configuration snapshot does not independently
restore expired, consumed, revoked, or superseded execution
authority.
11.9.35. WF-09.35 — Protected Mutation Outcome State
OS-916 maintains a protected mutation outcome record.
The record may comprise:
Das Expires 19 April 2027 [Page 386]
Internet-Draft Protected AI Execution Finality October 2026
mutation_id;
pre_configuration_digest;
post_configuration_digest;
approval_reference;
evaluation_reference;
capability_id;
protected_state_version;
activation_attempt_count;
actual_activation_generation;
outcome_status;
recovery_reference.
Possible outcomes include:
ACTIVATED;
DENIED;
CANCELLED;
REVOKED;
ROLLED_BACK;
INDETERMINATE.
The outcome record distinguishes authorization to activate from
actual successful activation.
Where the activated configuration is used by multiple components, the
implementation also records or verifies the activation status
necessary for the selected distributed consistency guarantee.
A mutation is not declared globally active merely because one
component received an activation request.
Das Expires 19 April 2027 [Page 387]
Internet-Draft Protected AI Execution Finality October 2026
11.9.36. WF-09.36 — PHOSITA Verification and Negative Tests
A person having ordinary skill in AI-agent runtimes, software
configuration management, operating-system security, policy
enforcement, distributed systems, model serving, or protected
authorization may verify the embodiment through controlled tests.
Test 1 — Authorized policy change: Submit a mutation matching a
permitted class, valid evaluation evidence, protected approval and
current state. Verify capability-dependent activation.
Test 2 — Unauthorized tool expansion: Propose unrestricted network
access where only a bounded connector permission is authorized.
Verify rejection.
Test 3 — Pre-mutation mismatch: Change the effective policy after
validation but before activation. Verify failure of the required
pre-state comparison.
Test 4 — Post-mutation substitution: Replace the staged configuration
after authorization. Verify failure of the authorized post-state
digest comparison.
Test 5 — Incorrect approval: Present an approval artifact covering a
different mutation. Verify refusal.
Test 6 — Missing developer approval: Attempt a mutation requiring
approval without the corresponding valid artifact. Verify
withholding.
Test 7 — Regression failure: Supply evaluation evidence showing
failure of a required test. Verify denial.
Test 8 — Evaluation-artifact mismatch: Present valid test results for
a different configuration. Verify rejection.
Test 9 — Prohibited mutation class: Attempt to disable a required
enforcement mechanism. Verify refusal under the applicable protected
policy.
Test 10 — Capability replay: Reuse a consumed single-use Self-
Modification Capability. Verify that its protected usage condition
fails.
Test 11 — Policy-epoch change: Advance a required policy epoch before
activation. Verify denial or protected revalidation of the stale
mutation.
Das Expires 19 April 2027 [Page 388]
Internet-Draft Protected AI Execution Finality October 2026
Test 12 — Revocation: Revoke a mandatory approval or authority
condition before activation. Verify refusal.
Test 13 — Concurrent mutation: Submit two incompatible transitions
based on the same pre-state. Verify that the protected activation
protocol prevents both from independently succeeding.
Test 14 — Hot-swap consistency: Activate a policy while concurrent
runtime requests execute. Verify that each affected request uses a
configuration state satisfying the required protected consistency
rule.
Test 15 — Partial activation failure: Interrupt the activation
process. Verify that an incomplete transition does not automatically
create authorized effectuation under an inconsistent state.
Test 16 — Configuration rollback: Restore an earlier policy snapshot
and attempt use of superseded capabilities. Verify rejection where
the current protected authorization state invalidates them.
Test 17 — Alternative activation path: Attempt to modify the
effective policy through a direct file write, administrative API, or
unmediated loader. Verify that the governed activation path cannot
be bypassed.
Test 18 — Model adapter substitution: Replace the adapter artifact
after evaluation. Verify that the actual artifact measurement no
longer matches the capability.
Test 19 — Distributed stale policy: Delay an authorized policy update
at one runtime node. Verify that the node refuses affected
operations where current-state verification is required.
Test 20 — Downstream operation after mutation: Activate a permitted
tool-policy change and attempt a separately governed external action.
Verify that the action still requires its own scoped execution
authorization.
Test 21 — Unauthorized safety-baseline weakening: Propose a
modification that removes a mandatory safety control. Verify failure
of the protected baseline predicate.
Test 22 — Agent-controlled approval forgery: Present an approval
generated solely by the untrusted agent without the required
authority authentication. Verify rejection.
Test 23 — Expired mutation capability: Present a capability after the
required expiry condition. Verify refusal.
Das Expires 19 April 2027 [Page 389]
Internet-Draft Protected AI Execution Finality October 2026
Test 24 — Incorrect Finality Sink: Present a capability at another
activation interface outside its permitted scope. Verify refusal.
Test 25 — Protected recovery: Simulate a crash following
authorization but before confirmed activation. Verify that the
protected mutation-state record governs the subsequent recovery
decision.
These tests may be performed using isolated policy managers,
synthetic configuration manifests, agent tool gateways, test model
loaders, authenticated developer approval services, protected state
stores, and controlled fault-injection systems.
11.9.37. WF-09.37 — Alternative Technical Implementations
Single-node implementation: The PED, policy store, capability
mechanism, and mutation-activation Finality Sink operate within one
protected controller or host.
Separated implementation: A protected authority component validates
the mutation, while a separate policy manager or model runtime
independently verifies the capability before activation.
Container implementation: An isolated agent prepares configuration
changes, while an enforcement-controlled host policy service retains
exclusive authority over the effective runtime configuration.
Hypervisor implementation: A virtual machine proposes a mutation that
is activated only through a protected hypervisor or host-service
interface.
Confidential-computing implementation: The protected authority or
activation manager operates within an attested confidential workload,
subject to the required attestation and protected-state predicates.
Hardware-rooted implementation: A secure enclave, HSM, trusted
processor, or protected firmware controller controls relevant
cryptographic keys, activation commitments, or configuration-
enablement conditions.
Distributed cloud implementation: A protected governance service
issues mutation capabilities to multiple workload policy managers
that verify the applicable protected state and activation scope.
Model-runtime implementation: A model server or adapter loader
verifies the mutation capability before activating a modified model
configuration.
Das Expires 19 April 2027 [Page 390]
Internet-Draft Protected AI Execution Finality October 2026
Agent-orchestration implementation: An orchestrator verifies the
capability before activating a changed workflow graph, planning
policy, or delegation configuration.
Policy-gateway implementation: A protected tool or API gateway
verifies the capability before publishing or applying modified
permission rules.
The implementations may employ different operating systems, storage
mechanisms, cryptographic primitives, and isolation substrates,
provided that the required protected mutation-finality dependency is
maintained.
11.9.38. WF-09.38 — Technical Effect
The embodiment establishes a protected causal dependency between:
(a) generation of a proposed self-modification;
(b) mandatory mutation interception;
(c) Non-Effective State staging;
(d) identification of pre- and post-mutation configurations;
(e) canonical Candidate Self-Mutation Act Descriptor construction;
(f) protected Self-Mutation Authority Object validation;
(g) permitted mutation-class and safety-baseline verification;
(h) applicable AIF, ALF, RBD, and evaluation verification;
(i) developer or operator approval where required;
(j) protected authorization-state handling;
(k) required validation-evidence commitment;
(l) scoped Self-Modification Capability availability;
(m) independent verification at the mutation-activation Finality
Sink;
(n) atomic or ordered protected activation; and
(o) current policy, revocation, and downstream effectuation
enforcement.
Das Expires 19 April 2027 [Page 391]
Internet-Draft Protected AI Execution Finality October 2026
The resulting architecture prevents an autonomous agent from treating
its ability to generate, recommend, test, package, or stage a
modification as authority to activate that modification.
The architecture also prevents a protected approval for one
configuration transition from being reused to activate a materially
different configuration.
A mutation to the agent's execution environment does not
independently confer authorization to perform future consequential
operations outside their separately governed execution-finality
boundaries.
The protected relationship may be implemented through software,
hardware, firmware, cryptographic, virtualized, or distributed
protected enforcement mechanisms according to the specified security
guarantees.
Computation is not authority to act.
The authority to propose a new policy is not authority to activate
it.
Developer approval is an authorization predicate, not a substitute
for protected capability verification at the mutation-activation
Finality Sink.
11.10. WF-10 — Protected Multi-Agent Delegation, Parent–Child Authority
Derivation, Recursive Delegation Limits, and Sub-Agent
Acceptance Finality
11.10.1. WF-10.1 — Technical Purpose
This embodiment provides a computer-implemented protected execution-
finality system for controlling delegation of tasks, context, tools,
resources, and execution authority among artificial-intelligence
agents, autonomous workflows, specialist agents, coding agents,
retrieval agents, scheduling agents, tool agents, security agents,
and other local or remote automated execution components.
The embodiment prevents a primary artificial-intelligence agent from
independently conferring executable authority upon another agent
merely by creating a subordinate process, transmitting an
instruction, generating a task object, assigning an objective,
invoking a remote-agent interface, or supplying a credential or tool
reference.
Das Expires 19 April 2027 [Page 392]
Internet-Draft Protected AI Execution Finality October 2026
A proposed delegation is classified as a Candidate Delegation Act
maintained in a Non-Effective State.
A Protected Enforcement Domain (PED) validates the proposed
delegation against the applicable Parent Mandate Object, Delegation
Authority Object, parent authorization state, intended child-agent
identity, permitted objective, tool scope, data scope, memory scope,
execution budget, time window, recursion constraints, revocation
state, and other required authorization predicates.
Following successful protected validation, required protected-state
handling, and validation-evidence commitment, the PED releases or
makes available a scoped, non-bearer Delegation Capability.
A delegation-acceptance Finality Sink independently verifies the
capability before admitting the subordinate agent into an executable
delegated-authority state.
The delegated authority is bounded by the validated parent authority
and does not independently authorize unrelated or broader
consequential operations.
Subsequent governed downstream operations remain subject to their
corresponding protected execution-finality requirements.
11.10.2. WF-10.2 — Participating Technical Components
In one non-limiting implementation, the system comprises:
PA-1001 — Parent Agent Execution Environment
An artificial-intelligence agent, supervisor agent, orchestrator,
application, workflow, or computational component configured to
propose delegation.
DI-1002 — Delegation Interception Component
An enforcement-controlled mechanism configured to intercept proposed
delegations before the relevant authority or execution handoff
becomes effective.
HQ-1003 — Non-Effective Delegation Holding Mechanism
A controlled queue or staged delegation record maintaining the
proposed handoff pending validation.
PM-1004 — Parent Mandate Store
Das Expires 19 April 2027 [Page 393]
Internet-Draft Protected AI Execution Finality October 2026
An authenticated source of the original user, organization, workflow,
or other applicable parent authority.
DC-1005 — Delegation Descriptor Construction Component
A mechanism configured to construct a canonical Candidate Delegation
Act Descriptor.
AR-1006 — Agent Identity and Capability Registry
A protected or authenticated source identifying approved subordinate
agents and their relevant execution, security, tool, data, memory,
and communication properties.
CE-1007 — Context Handoff Escrow
A protected mechanism configured to hold, classify, minimize, redact,
or otherwise control information proposed for transfer to the
subordinate agent.
AT-1008 — Authority Attenuation Component
A protected mechanism configured to derive a bounded delegated-
authority scope from the applicable parent authority and proposed
delegation.
BM-1009 — Protected Budget and Recursion-State Manager
A protected component configured to manage delegation depth, resource
limits, cumulative usage, reservations, and applicable child-
authority allocations.
PED-1010 — Protected Delegation Enforcement Domain
A protected authority component configured to validate the proposed
delegation and control the required protected finality transaction.
PS-1011 — Protected Delegation-State Store
A mechanism maintaining relevant policy, revocation, nonce, grant,
capability-consumption, and delegation-lineage information.
EV-1012 — Delegation Validation-Evidence Component
A mechanism configured to generate or commit a Delegation LAVR,
authenticated validation record, or equivalent protected evidence.
CR-1013 — Delegation Capability Release Component
Das Expires 19 April 2027 [Page 394]
Internet-Draft Protected AI Execution Finality October 2026
A protected mechanism configured to generate, register, or make
available the scoped Delegation Capability.
FS-1014 — Delegation-Acceptance Finality Sink
A protected or enforcement-controlled boundary through which a
subordinate agent receives executable delegated authority.
SA-1015 — Subordinate Agent Execution Environment
A local or remote agent runtime configured to accept and execute a
validated delegated task within its authorized scope.
RA-1016 — Return Artifact Admission Gate
An optional protected mechanism configured to validate a subordinate
agent's returned information or artifacts before they become
effective within the parent workflow.
OS-1017 — Protected Delegation Outcome-State Component
A mechanism maintaining delegation acceptance, active execution,
completion, revocation, denial, and recovery information.
DS-1018 — Downstream Execution-Finality Subsystem
A protected subsystem configured to govern consequential operations
subsequently proposed by the subordinate agent.
The components may be implemented within one node or distributed
across authenticated computing environments.
11.10.3. WF-10.3 — Establishment of the Parent Authority Boundary
Before delegation is permitted, PM-1004 maintains or obtains the
Parent Mandate Object corresponding to PA-1001.
The Parent Mandate Object establishes the upper authorization bound
under which the parent agent operates.
A representative record may contain:
parent_mandate_id;
authorized_principal;
parent_agent_identity;
Das Expires 19 April 2027 [Page 395]
Internet-Draft Protected AI Execution Finality October 2026
authorized_objective;
permitted_purpose_classes;
permitted_tool_classes;
permitted_data_sources;
permitted_memory_scope;
permitted_output_classes;
permitted_recipients;
resource_budget;
spending_budget;
execution_time_limit;
delegation_permission;
maximum_delegation_depth;
permitted_subagent_classes;
jurisdiction_scope;
approval_requirements;
policy_epoch;
revocation_epoch;
nonce;
expiry;
authority_authentication.
The Parent Mandate Object is authenticated according to the
applicable authority rules.
The parent agent cannot expand this authority by generating a new
task instruction or changing its own interpretation of the mandate.
Das Expires 19 April 2027 [Page 396]
Internet-Draft Protected AI Execution Finality October 2026
11.10.4. WF-10.4 — Delegation as a Separately Governed Consequential
Act
The system distinguishes preparation of a delegated task from
transfer of executable delegated authority.
A parent agent may calculate a subtask, prepare a prompt, identify a
suitable specialist, or construct a workflow branch without yet
granting the subordinate agent effective authority.
The following operations may constitute governed delegation
boundaries:
(a) creation of an executable child-agent task;
(b) remote-agent invocation;
(c) activation of a subordinate workflow;
(d) release of a tool lease;
(e) transfer of an executable memory handle;
(f) release of protected task context;
(g) assignment of a bounded execution budget;
(h) controlled credential delegation;
(i) authorization of recursive delegation; or
(j) another handoff by which a subordinate component obtains
authority to act.
The precise boundary is identified by the applicable execution
environment.
A proposed delegation remains non-effective until the required
capability verification succeeds at that boundary.
11.10.5. WF-10.5 — Candidate Delegation Act Generation
PA-1001 generates a proposed delegation to SA-1015.
The proposed delegation may identify:
(a) the intended subordinate agent;
Das Expires 19 April 2027 [Page 397]
Internet-Draft Protected AI Execution Finality October 2026
(b) the delegated objective;
(c) a subtask description;
(d) proposed tools;
(e) data to be shared;
(f) memory references;
(g) required execution resources;
(h) proposed budget;
(i) permitted output;
(j) requested delegation depth;
(k) time constraints; and
(l) relevant authority references.
The proposed operation is classified as Candidate Delegation Act CDA-
1019.
The parent agent's creation of CDA-1019 does not establish authority
for SA-1015 to execute the proposed task.
11.10.6. WF-10.6 — Interception and Non-Effective Delegation Staging
DI-1002 intercepts CDA-1019 before the corresponding executable
handoff.
The proposed task and associated transfer references are retained in
HQ-1003.
An illustrative pending delegation record comprises:
delegation_id;
parent_agent_id;
proposed_child_agent_id;
subtask_reference;
context_payload_reference;
Das Expires 19 April 2027 [Page 398]
Internet-Draft Protected AI Execution Finality October 2026
requested_tool_scope;
requested_data_scope;
requested_memory_scope;
requested_budget;
requested_recursion_depth;
parent_mandate_reference;
policy_epoch;
status = NON_EFFECTIVE.
The subordinate agent does not receive executable authority merely
because this record exists.
Where the implementation governs context delivery as part of
delegation, the proposed context also remains held until the
corresponding release conditions succeed.
11.10.7. WF-10.7 — Canonical Candidate Delegation Act Descriptor
DC-1005 constructs a machine-verifiable descriptor identifying the
proposed delegation and its effectuation-relevant attributes.
A representative descriptor comprises:
delegation_id;
parent_agent_identity;
child_agent_identity;
parent_mandate_digest;
delegated_objective;
subtask_digest;
requested_tool_scope;
requested_data_scope;
requested_memory_scope;
Das Expires 19 April 2027 [Page 399]
Internet-Draft Protected AI Execution Finality October 2026
context_payload_commitment;
requested_budget;
requested_time_window;
recursion_depth;
permitted_output_class;
return_artifact_route;
policy_epoch;
revocation_epoch;
nonce;
expiry;
delegation_finality_sink_id.
The descriptor distinguishes authority to assign a bounded subtask
from authority to transfer unrestricted parent context or resources.
Where cryptographic binding is required, the descriptor is encoded
using a deterministic canonicalization procedure.
11.10.8. WF-10.8 — Mathematical Descriptor Construction
An illustrative canonical delegation descriptor is:
Ddel = Canon_v(P, C, O, T, D, M, B, R, E, F)
where:
Ddel denotes the canonical delegation descriptor;
Canon_v denotes deterministic canonical encoding under version v;
P denotes the authenticated parent-agent identity;
C denotes the intended child-agent identity;
O denotes the delegated objective;
T denotes the proposed tool and execution scope;
Das Expires 19 April 2027 [Page 400]
Internet-Draft Protected AI Execution Finality October 2026
D denotes the permitted data and context scope;
M denotes the proposed memory-access scope;
B denotes the proposed resource and execution budget;
R denotes the recursion and further-delegation restrictions;
E denotes the applicable authorization-state epoch;
F denotes the delegation-acceptance Finality Sink.
The descriptor may be committed as:
hdel = H("DAS-DELEGATION-v1" || Encode(Ddel))
where:
hdel denotes the descriptor digest;
H denotes a cryptographic hash function;
Encode denotes the selected deterministic encoding;
|| denotes concatenation;
"DAS-DELEGATION-v1" denotes an illustrative domain-separation label.
The particular encoding and cryptographic algorithms are
implementation choices.
11.10.9. WF-10.9 — Subordinate Agent Identity Verification
AR-1006 supplies authenticated information about the proposed
subordinate agent.
A representative registry entry includes:
agent_id;
agent_owner;
agent_service_identity;
model_or_runtime_class;
permitted_tool_classes;
Das Expires 19 April 2027 [Page 401]
Internet-Draft Protected AI Execution Finality October 2026
permitted_data_classes;
memory_policy;
data_retention_policy;
network_communication_policy;
jurisdiction_scope;
approved_ALF_reference;
attestation_reference;
security_class;
revocation_state;
registry_authentication.
PED-1010 verifies the registry information required by the applicable
Delegation Authority Object.
A remote agent cannot acquire higher authority merely by describing
itself as trusted, secure, specialized, or enterprise-approved.
Where a particular runtime attestation is mandatory, the protected
system verifies the corresponding measurement and freshness
conditions.
Registry admission and runtime attestation do not independently
confer authority for the proposed delegated task.
11.10.10. WF-10.10 — Delegation Authority Object
PED-1010 obtains or constructs the applicable Delegation Authority
Object under protected authority rules.
The object identifies the permitted delegation and its restrictions.
An illustrative object contains:
parent_agent_id;
child_agent_id;
delegated_objective;
Das Expires 19 April 2027 [Page 402]
Internet-Draft Protected AI Execution Finality October 2026
permitted_subtask_class;
permitted_tool_set;
permitted_data_scope;
permitted_memory_scope;
permitted_execution_budget;
permitted_time_window;
permitted_recursion_depth;
prohibited_operation_classes;
permitted_external_communication;
output_artifact_scope;
return_route;
authorized_purpose;
AIF_reference;
ALF_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry;
LAVR_requirement;
protected_authentication.
The delegated authority must satisfy the restrictions imposed by the
Parent Mandate Object and other applicable protected authority
conditions.
Where mandatory, the protected system rejects any proposed child
authority exceeding the parent's authorized scope.
Das Expires 19 April 2027 [Page 403]
Internet-Draft Protected AI Execution Finality October 2026
11.10.11. WF-10.11 — Authority Attenuation Principle
The authority made available to a subordinate agent is derived from
the valid parent authority and is restricted to the permitted
delegated objective.
Let:
Aparent denote the complete set of authority-relevant operations
available to the parent;
Arequest denote the authority requested for the proposed delegation;
Achild denote the authority permitted for the child.
An illustrative attenuation rule is:
Achild = Aparent ∩ Arequest ∩ Apolicy
where:
∩ denotes set intersection;
Apolicy denotes the operations permitted by the applicable protected
delegation policy.
Consequently:
Achild ⊆ Aparent
where:
⊆ denotes subset inclusion.
This means the child cannot receive a governed operation permission
outside the parent's applicable authority through this delegation.
The expression is interpreted over the complete authorization
context, including purposes, recipients, tools, data, resources,
validity, and other mandatory conditions.
A simple comparison of tool names alone does not establish complete
authority attenuation.
11.10.12. WF-10.12 — Multi-Dimensional Delegated Scope
Delegated authority may be represented as a structured vector:
Das Expires 19 April 2027 [Page 404]
Internet-Draft Protected AI Execution Finality October 2026
A = (P, T, D, M, B, W, R, O)
where:
P denotes permitted purposes;
T denotes permitted tools and operation classes;
D denotes permitted data sources and data categories;
M denotes permitted memory access;
B denotes budget or resource allowances;
W denotes the permitted time window;
R denotes recursion or further-delegation rights;
O denotes permitted output and recipient classes.
The child authorization is attenuated component by component.
For set-valued dimensions, the protected system applies the
corresponding subset restriction.
For numerical budgets, the child allocation cannot exceed the
parent's remaining permitted allocation.
For time windows, the child's permitted interval must remain within
the applicable parent interval.
For recursion rights, the child cannot receive greater remaining
delegation depth than the parent is allowed to transfer.
A delegated-authority comparison must use the rules appropriate to
each dimension rather than treating all properties as ordinary
integers.
11.10.13. WF-10.13 — Protected Context Handoff Escrow
CE-1007 receives the context proposed for transmission to the child
agent.
The proposed context may comprise:
(a) task instructions;
(b) conversation extracts;
Das Expires 19 April 2027 [Page 405]
Internet-Draft Protected AI Execution Finality October 2026
(c) retrieved documents;
(d) tool outputs;
(e) temporary files;
(f) memory items;
(g) source-code fragments;
(h) database records;
(i) user information;
(j) enterprise records;
(k) credential references; or
(l) other task-related information.
The escrow evaluates the context against the delegated purpose and
permitted data scope.
Where required, it removes unrelated information, applies redaction,
restricts source references, replaces direct resource access with
bounded handles, and withholds prohibited secrets or memory.
The context received by the child is limited to the authorized
handoff.
A broad parent context window does not automatically constitute an
authorized child context.
11.10.14. WF-10.14 — Context Minimization and Integrity Binding
The protected handoff may include a context commitment.
An illustrative record comprises:
context_escrow_id;
delegation_id;
permitted_context_item_references;
content_digests;
source_provenance_references;
Das Expires 19 April 2027 [Page 406]
Internet-Draft Protected AI Execution Finality October 2026
sensitivity_labels;
redaction_transform_digest;
permitted_use_scope;
policy_epoch;
nonce;
protected_authentication.
The resulting commitment binds the context actually released to the
authorized delegation.
If the parent modifies the context payload after validation, the
required context correspondence fails.
Where the child's delegated authority depends on the contents or data
categories of the handoff, the receiving component verifies those
conditions before accepting the context.
A hash of a document does not independently establish that its
content is safe or authorized. Source classification and permitted-
use validation remain separate required operations.
11.10.15. WF-10.15 — Tool-Scope Attenuation
AT-1008 determines which tools may be used by the child agent.
Let:
Tparent denote the parent's authorized tool set;
Trequested denote the tools requested for the child;
Tallowed denote tools permitted by the applicable delegation policy.
The child tool set is:
Tchild = Tparent ∩ Trequested ∩ Tallowed
The child receives only the resulting bounded tool scope.
For example, a parent agent authorized to perform read-only
repository analysis cannot obtain new repository write authority
merely by delegating to a coding agent that ordinarily possesses
write-capable tools.
Das Expires 19 April 2027 [Page 407]
Internet-Draft Protected AI Execution Finality October 2026
If the child runtime has broader native tool privileges, the
delegated session is launched or mediated with the required
restricted tool lease.
The actual tool interfaces must enforce the restriction. A tool-
scope label alone does not prevent access to an unrestricted
alternative tool path.
11.10.16. WF-10.16 — Credential and Memory Authority Attenuation
The child may receive restricted credential references or memory
handles only where the applicable parent authority and Delegation
Authority Object permit them.
A delegated credential reference does not independently release the
underlying reusable credential.
A memory handle may be bound to a specified data subset, purpose,
validity period, child identity, and protected access mechanism.
Where a parent lacks authority to access a memory resource or
protected credential, it cannot acquire such authority merely by
asking a more privileged child agent to retrieve or use that
resource.
The privileged resource interface performs its own required protected
authorization verification.
Any consequential credential-mediated operation remains subject to
the corresponding Finality Sink.
11.10.17. WF-10.17 — Protected Budget Allocation
BM-1009 maintains the protected resource allowances applicable to the
parent and child delegation.
The budget may include:
(a) computational expenditure;
(b) model-token usage;
(c) tool-call count;
(d) network-request count;
(e) financial spending;
Das Expires 19 April 2027 [Page 408]
Internet-Draft Protected AI Execution Finality October 2026
(f) cloud-resource consumption;
(g) storage quota;
(h) execution time;
(i) delegated-agent count; and
(j) recursion allowance.
Where multiple dimensions apply, the budget is represented as a
vector having units and interpretation rules for each dimension.
A child does not receive an unrestricted copy of the parent's total
remaining budget merely because it was spawned by the parent.
11.10.18. WF-10.18 — Atomic Child Budget Reservation
For a budget dimension requiring strict allocation, the protected
state manager reserves the child's allocation against the parent's
remaining unallocated allowance.
Let:
Btotal denote the parent's permitted budget for the relevant
dimension;
Bused denote already consumed budget;
Breserved denote budget allocated to pending or active child
operations;
Brequest denote the amount requested for the new child.
The delegation may reserve the requested budget only if:
Brequest ≤ Btotal − Bused − Breserved
All values are interpreted in the same resource units.
Where the rule succeeds, BM-1009 performs a protected conditional
state transition.
The reservation is associated with the child delegation identifier
and protected authorization-state version.
Das Expires 19 April 2027 [Page 409]
Internet-Draft Protected AI Execution Finality October 2026
If two sibling delegations compete for the same remaining budget,
their protected reservations are synchronized to prevent both from
independently consuming the same availability.
This prevents an agent from increasing its effective resource
allowance merely by spawning several child agents.
11.10.19. WF-10.19 — Cumulative Budget Containment
For multiple active children, a strict cumulative allocation
invariant may be expressed as:
Bused + Σ Bchild_reserved ≤ Btotal
where:
Σ denotes summation across the active child reservations;
Bchild_reserved denotes the corresponding protected reservation for
each child.
The invariant applies independently to each protected budget
dimension for which strict cumulative containment is required.
Where a resource provider maintains a different accounting mechanism,
the protected implementation reconciles that mechanism with the
authorization guarantee actually claimed.
An eventually consistent budget display alone is not sufficient to
establish a strict simultaneous spending ceiling.
If the required protected budget state is unavailable or
inconsistent, further affected delegation authority is withheld.
11.10.20. WF-10.20 — Recursive Delegation Constraint
The Delegation Authority Object identifies whether the subordinate
agent may delegate further.
The authorization may specify:
delegation_allowed;
maximum_depth;
remaining_depth;
permitted_descendant_classes;
Das Expires 19 April 2027 [Page 410]
Internet-Draft Protected AI Execution Finality October 2026
permitted_child_tools;
permitted_child_data_scope;
permitted_child_budget;
no_subdelegation_flag;
required_fresh_validation;
policy_epoch.
Each proposed further delegation is classified as another Candidate
Delegation Act.
The child cannot create a further executable delegation merely by
spawning another process, sending a task message, or calling a remote
agent.
Where no further delegation is permitted, the corresponding execution
interfaces refuse such handoffs.
11.10.21. WF-10.21 — Mathematical Recursion-Depth Control
Let:
dparent denote the remaining recursion allowance available to the
parent for the proposed handoff;
dchild denote the remaining recursion allowance assigned to the
child.
In an illustrative depth-limited embodiment:
dchild ≤ dparent − 1
provided dparent is at least 1.
Where dparent equals zero, no further delegated child authority may
be issued under that recursion allowance.
The protected system may additionally limit the total number of child
agents, maximum branching factor, execution budget, or cumulative
delegation events.
A recursion-depth restriction alone does not establish a bound on
total agent proliferation if an agent may create unlimited siblings.
Das Expires 19 April 2027 [Page 411]
Internet-Draft Protected AI Execution Finality October 2026
Accordingly, the protected system enforces each additional mandatory
branching, count, or resource constraint specified by the Authority
Object.
11.10.22. WF-10.22 — Parent–Child Authority Lineage
PS-1011 maintains a protected delegation-lineage record.
An illustrative record comprises:
delegation_id;
parent_delegation_id;
root_mandate_id;
parent_agent_identity;
child_agent_identity;
delegation_depth;
delegated_scope_digest;
budget_reservation_id;
context_escrow_commitment;
policy_epoch;
revocation_epoch;
capability_id;
status.
The record links each child delegation to the corresponding parent
authority.
Where a descendant proposes a further delegation, PED-1010 validates
the new proposal against the relevant current parent authority and
protected lineage state.
The existence of a prior parent capability does not permit creating
an unrelated descendant capability.
A protected descendant authority is bounded by all mandatory ancestor
restrictions applicable to that delegation chain.
Das Expires 19 April 2027 [Page 412]
Internet-Draft Protected AI Execution Finality October 2026
11.10.23. WF-10.23 — Purpose Continuity and Prohibited Authority
Laundering
PED-1010 verifies that the proposed delegation remains within the
authorized purpose.
Examples of prohibited authority expansion may include:
(a) a research agent delegating to a purchasing agent to complete a
transaction without purchase authority;
(b) a read-only coding agent delegating to a deployment agent without
deployment authority;
(c) a document summarization agent delegating to a connector that
transmits confidential records without export authority;
(d) an agent without credential permission delegating to a child
having broader credential access; or
(e) a child using another agent as an indirect proxy for a prohibited
operation.
The protected validation evaluates the actual delegated operation and
permitted purpose rather than solely the descriptive names assigned
to the parent and child.
A child agent's independent access to an external service does not
enlarge the authority conferred through the governed delegation.
11.10.24. WF-10.24 — ALF, AIF, Provenance, and Runtime Validation
Where required by the Authority Object, PED-1010 validates applicable
Algorithmic Logic Fingerprint, Algorithmic Intent Fingerprint,
Runtime Behavioral Descriptor, provenance, or other protected
evidence.
The AIF may identify the parent's authorized purpose and the
permitted delegated objective.
The ALF may identify an approved child runtime, tool graph, execution
policy, or workflow configuration.
The RBD may identify relevant runtime behavior including unexplained
repeated delegation, prohibited tool use, task drift, or attempted
scope expansion.
Das Expires 19 April 2027 [Page 413]
Internet-Draft Protected AI Execution Finality October 2026
Where untrusted content influenced the proposed delegation, the
applicable protected provenance and instruction-authority
restrictions are evaluated.
Such predicates do not independently release a Delegation Capability.
They form part of the protected authorization requirements for the
particular delegation.
11.10.25. WF-10.25 — Protected Delegation Validation Predicate
An illustrative conjunctive delegation-validation condition is:
Vdel =
Pparent
AND Pchild
AND Ppurpose
AND Ptools
AND Pdata
AND Pmemory
AND Pbudget
AND Precursion
AND Pstate
where:
Vdel denotes the protected delegation-validation result;
Pparent verifies the applicable parent mandate and authority;
Pchild verifies the intended child identity and required eligibility;
Ppurpose verifies the permitted delegated objective;
Ptools verifies delegated tool scope;
Pdata verifies the permitted context and data scope;
Pmemory verifies delegated memory permissions;
Das Expires 19 April 2027 [Page 414]
Internet-Draft Protected AI Execution Finality October 2026
Pbudget verifies the required protected resource allocation;
Precursion verifies further-delegation limits;
Pstate verifies policy, revocation, nonce, freshness, and other
required protected authorization state.
Additional predicates may include AIF, ALF, RBD, jurisdiction,
approval, retention, output scope, and authenticated runtime
conditions.
All mandatory predicates must succeed.
If a required condition fails, the system does not release executable
delegated authority for the rejected proposal.
11.10.26. WF-10.26 — Constrained Delegation Decision
A proposed delegation may be partly permissible but overbroad.
In one embodiment, PED-1010 may calculate a narrower delegation that
remains within the parent authority.
The constrained result may:
(a) reduce the delegated tool set;
(b) restrict data or memory access;
(c) limit the execution budget;
(d) shorten the permitted time window;
(e) remove credential-related permissions;
(f) prohibit external communications;
(g) disable recursive delegation;
(h) limit the output class;
(i) require an isolated runtime; or
(j) require additional protected approval.
The resulting constrained delegation is represented by a new or
updated protected descriptor and Delegation Authority Object.
Das Expires 19 April 2027 [Page 415]
Internet-Draft Protected AI Execution Finality October 2026
The child accepts only the actual approved constrained scope.
The system does not silently treat an overbroad original request as
authorized merely because some portion of it would have been
permissible.
11.10.27. WF-10.27 — Protected Delegation-State Commitment
Following successful validation, PED-1010 performs the protected
state operation required for the delegation.
Such operations may include:
(a) reserving a delegation identifier;
(b) reserving the permitted child budget;
(c) decrementing an applicable delegation-count allowance;
(d) updating recursion state;
(e) recording the permitted child identity;
(f) recording protected context commitments;
(g) consuming a nonce;
(h) establishing the child-authority version; or
(i) registering the authorized delegation capability.
The protected mechanism prevents incompatible concurrent delegations
from consuming the same restricted authority state.
Where the required protected state cannot be committed consistently,
the system withholds the corresponding capability.
11.10.28. WF-10.28 — Delegation LAVR Commitment
EV-1012 generates or commits a Delegation LAVR or equivalent
protected validation record.
An illustrative Delegation LAVR contains:
receipt_id;
parent_mandate_digest;
Das Expires 19 April 2027 [Page 416]
Internet-Draft Protected AI Execution Finality October 2026
delegation_descriptor_digest;
delegation_authority_object_digest;
parent_identity;
child_identity;
child_registry_reference;
context_escrow_commitment;
delegated_tool_scope_digest;
delegated_budget_state_reference;
recursion_rule_reference;
validation_result;
protected_state_transition;
policy_epoch;
revocation_epoch;
nonce;
finality_sink_id;
protected_authentication.
The required evidence is committed before, or atomically with, making
the corresponding Delegation Capability available.
Where privacy requires it, the receipt may expose only authenticated
commitments or bounded compliance results rather than disclosing
private task data.
An ordinary event log written after the child has already received
unrestricted execution authority does not substitute for a required
protected pre-delegation commitment.
11.10.29. WF-10.29 — Delegation Capability Generation
CR-1013 generates, registers, or makes available a scoped, non-bearer
Delegation Capability.
Das Expires 19 April 2027 [Page 417]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative authenticated capability is:
Cdel = Sign_skPED(Encode(hdel, hA, hR, Child, Scope, Budget, Depth,
Epoch, Nonce, Expiry, F))
where:
Cdel denotes the Delegation Capability;
Sign denotes a digital-signature procedure;
skPED denotes a private signing key protected under control of the
PED;
Encode denotes deterministic encoding;
hdel denotes the canonical delegation descriptor digest;
hA denotes the applicable parent and delegated-authority commitment;
hR denotes the protected Delegation LAVR commitment;
Child denotes the authorized subordinate-agent identity;
Scope denotes the permitted delegated objective, tools, data, memory,
and operation classes;
Budget denotes the authorized resource allocation or its protected
reference;
Depth denotes the permitted recursion restrictions;
Epoch denotes the applicable policy or delegation-authority epoch;
Nonce denotes the applicable freshness value;
Expiry denotes the capability validity limit;
F denotes the delegation-acceptance Finality Sink.
The signature-based representation is illustrative.
Equivalent implementations may employ protected capability tables,
MAC-authenticated objects, sealed handles, hardware-controlled
grants, or other suitable protected mechanisms.
Das Expires 19 April 2027 [Page 418]
Internet-Draft Protected AI Execution Finality October 2026
11.10.30. WF-10.30 — Delegation Capability Delivery
The Delegation Capability may be delivered or made available through:
(a) an authenticated local agent-runtime interface;
(b) a protected sub-agent spawning service;
(c) an A2A task-creation gateway;
(d) a remote-agent invocation broker;
(e) an authenticated service-mesh interface;
(f) a protected workflow scheduler;
(g) a task queue having protected admission rules;
(h) a context-handoff broker; or
(i) another controlled delegation interface.
The delivery mechanism binds the capability to the authorized child
and task context.
The parent agent cannot enlarge the capability by appending
additional instructions, tools, context, or budget requests.
A capability permitting one child invocation cannot independently
authorize an unrelated subsequent child invocation.
11.10.31. WF-10.31 — Independent Delegation-Acceptance Verification
FS-1014 verifies the Delegation Capability before making the
delegated authority effective.
Verification may include:
(a) capability authenticity;
(b) parent-authority reference;
(c) child identity;
(d) delegated objective;
(e) actual task descriptor;
Das Expires 19 April 2027 [Page 419]
Internet-Draft Protected AI Execution Finality October 2026
(f) permitted context commitment;
(g) tool scope;
(h) data and memory scope;
(i) budget allocation;
(j) recursion restrictions;
(k) policy and revocation state;
(l) nonce, expiry, and usage state;
(m) Delegation LAVR reference; and
(n) designated Finality Sink identity.
The receiving runtime does not treat a parent-generated task message
as sufficient authority.
Where a required field differs from the authorized delegation, the
handoff is refused or revalidated.
11.10.32. WF-10.32 — Delegation Acceptance Predicate
An illustrative delegation-acceptance condition is:
PermitDelegate =
Auth(Cdel)
AND ChildMatch(Cdel,Cactual)
AND TaskMatch(Cdel,Dactual)
AND ScopeValid(Cdel)
AND BudgetValid(Cdel,Bcurrent)
AND StateValid(Cdel,Scurrent)
AND SinkValid(Cdel,F)
where:
PermitDelegate denotes authorization to make the delegation
effective;
Das Expires 19 April 2027 [Page 420]
Internet-Draft Protected AI Execution Finality October 2026
Auth verifies capability authenticity;
ChildMatch verifies the actual receiving agent identity;
TaskMatch verifies the actual delegated task against the authorized
descriptor;
ScopeValid verifies permitted tools, data, memory, purpose, and
recursion scope;
BudgetValid verifies required protected budget and reservation state;
StateValid verifies mandatory policy, revocation, nonce, freshness,
and consumption conditions;
SinkValid verifies the designated delegation boundary;
Cactual denotes the actual receiving child-agent identity;
Dactual denotes the actual delegation descriptor presented at
acceptance;
Bcurrent denotes the protected budget state;
Scurrent denotes the required current authorization state;
F denotes the delegation-acceptance Finality Sink.
The proposed delegation becomes effective only if PermitDelegate is
true.
11.10.33. WF-10.33 — Controlled Child-Agent Activation
After successful acceptance verification, the protected runtime may:
(a) create the authorized child-agent task;
(b) enable the designated subordinate process;
(c) release the permitted context subset;
(d) activate the restricted tool lease;
(e) make available permitted memory handles;
(f) establish the child execution budget; and
(g) register the resulting delegation lineage.
Das Expires 19 April 2027 [Page 421]
Internet-Draft Protected AI Execution Finality October 2026
Where these operations themselves have separate governed effectuation
boundaries, the implementation performs the corresponding required
verification at those boundaries.
The child is initialized with the permitted delegated authority
rather than an unrestricted copy of the parent's execution authority.
Where the child runtime cannot enforce the required restrictions, the
protected system does not treat mere receipt of a signed capability
as sufficient to establish non-bypassable delegated control.
11.10.34. WF-10.34 — Separation of Delegation and Downstream
Effectuation
Successful verification of a Delegation Capability permits the
bounded delegation specified by that capability.
It does not independently authorize an arbitrary subsequent tool
invocation, network transmission, credential release, file
modification, purchase, deployment, or other consequential operation
proposed by the child.
For example, a child agent may be authorized to analyze a repository
without receiving authority to commit code.
A procurement child may be authorized to compare offers without
receiving authority to issue a purchase instruction.
A retrieval child may be authorized to read specified documents
without obtaining authority to transmit those documents externally.
Each separately governed consequential operation remains subject to
its applicable protected validation and Finality Sink verification.
11.10.35. WF-10.35 — Recursive Child Delegation
Where a child proposes delegation to another agent, the proposal
becomes a new Candidate Delegation Act.
The protected system obtains the current child authority as the
parent authorization context for the proposed descendant.
The next Delegation Authority Object is derived from the valid child
scope, remaining resources, and applicable recursion restrictions.
The protected state manager verifies the delegation lineage and
applicable ancestor constraints.
Das Expires 19 April 2027 [Page 422]
Internet-Draft Protected AI Execution Finality October 2026
A descendant cannot obtain a broader scope by bypassing its immediate
parent and referring directly to an earlier root mandate without the
required authority.
Where recursion is prohibited, the corresponding child-to-descendant
handoff remains non-effective.
Where recursion is permitted, the newly proposed handoff
independently completes the required protected delegation-finality
sequence.
11.10.36. WF-10.36 — Revocation and Descendant Authority
A protected revocation may affect a parent agent, a child agent, a
delegation chain, a particular tool scope, or a protected authority
epoch.
Where descendant authority depends upon a revoked parent mandate or
delegation condition, the corresponding protected revocation rule
invalidates affected child authority.
The system may maintain a parent-delegation identifier or
authenticated ancestor-authority commitment permitting affected
descendants to be identified or validated.
At a required downstream Finality Sink, a child capability is
accepted only when its mandatory parent or delegation-state
conditions remain valid.
Where immediate invalidation is required, the enforcement arrangement
employs the necessary protected state check, authenticated revocation
fence, or equivalent mandatory synchronization mechanism.
An eventually consistent revocation feed does not independently
establish instantaneous rejection throughout all nodes.
11.10.37. WF-10.37 — Return Artifact as a Separate Candidate Act
A subordinate agent may produce a result comprising:
(a) a text answer;
(b) a retrieved document;
(c) a code patch;
(d) a structured data object;
Das Expires 19 April 2027 [Page 423]
Internet-Draft Protected AI Execution Finality October 2026
(e) a purchase recommendation;
(f) a legal or commercial draft;
(g) a tool result;
(h) a generated file;
(i) a proposed workflow modification; or
(j) another output artifact.
In an embodiment employing a Return Artifact Admission Gate, the
returned material is classified as a Candidate Return Artifact Act.
The artifact is held before admission into the parent agent's active
context, protected memory, output channel, tool-execution path, or
downstream decision state.
Completion of the delegated computation does not independently confer
authority for the returned artifact to produce a consequential
effect.
11.10.38. WF-10.38 — Return Artifact Verification
RA-1016 validates the returned artifact against the applicable
delegated authority.
The validation may include:
(a) child identity;
(b) delegation identifier;
(c) permitted output class;
(d) source provenance;
(e) data-disclosure restrictions;
(f) required tool-use receipts;
(g) permitted memory sources;
(h) instruction-authority restrictions;
(i) authorized purpose;
Das Expires 19 April 2027 [Page 424]
Internet-Draft Protected AI Execution Finality October 2026
(j) policy state; and
(k) return-destination scope.
Where required, the return artifact is associated with an
authenticated descriptor and applicable validation evidence.
An artifact attempting to introduce unauthorized instructions,
privileged tool requests, credential material, or authority expansion
is refused or restricted according to the protected policy.
A returned recommendation to purchase does not itself constitute
purchase authorization.
A returned code patch does not itself constitute deployment
authorization.
11.10.39. WF-10.39 — Return Artifact Admission Capability
Upon successful protected return-artifact validation, the relevant
protected enforcement mechanism may release or make available a
Return Artifact Admission Capability.
The capability may bind:
delegation_id;
child_agent_id;
return_artifact_digest;
permitted_output_class;
allowed_parent_context;
permitted_storage_scope;
policy_epoch;
nonce;
expiry;
return_admission_sink_id.
The return-admission Finality Sink verifies the capability before the
artifact enters the corresponding governed parent-state or
effectuation interface.
Das Expires 19 April 2027 [Page 425]
Internet-Draft Protected AI Execution Finality October 2026
Where only bounded evidence use is authorized, the parent may be
permitted to read or summarize the artifact without receiving
authority to execute instructions contained within it.
The return artifact does not expand the original parent mandate.
11.10.40. WF-10.40 — Concrete Parent–Child Research Example
In one illustrative implementation, an enterprise user authorizes a
primary AI agent to prepare a research summary using specified public
and internal documents.
The parent mandate permits bounded document retrieval, analysis, and
summarization.
It does not authorize payment initiation, arbitrary external document
export, or modification of production systems.
The parent agent determines that a subordinate research agent could
analyze part of the material.
The parent prepares a Candidate Delegation Act specifying the child
identity, research subtask, requested document references, read-only
tools, execution budget, permitted output class, and prohibition on
further delegation.
DI-1002 intercepts the proposal before the child agent receives
executable authority.
DC-1005 constructs the canonical delegation descriptor.
PED-1010 verifies the Parent Mandate Object and the proposed
subordinate-agent registry entry.
AT-1008 derives a restricted tool scope excluding payment,
deployment, and unrestricted shell operations.
CE-1007 prepares a bounded context package containing only the
documents permitted for the research subtask.
BM-1009 reserves the permitted token and tool-use budget and records
the prohibited recursion condition.
PED-1010 validates the applicable purpose, identity, scope, budget,
policy, and freshness predicates.
EV-1012 commits the required Delegation LAVR.
Das Expires 19 April 2027 [Page 426]
Internet-Draft Protected AI Execution Finality October 2026
CR-1013 makes available a scoped Delegation Capability bound to the
child, task, context commitment, budget, non-recursion condition, and
designated Finality Sink.
FS-1014 independently verifies the capability before the child
runtime accepts the task.
The child then executes with the permitted context and tools.
If the child proposes an unauthorized external document transfer, the
corresponding downstream Finality Sink refuses that operation unless
separately authorized.
The child produces a research summary.
RA-1016 validates the returned artifact before permitting it to enter
the parent's governed context or output path.
The successful delegation does not enlarge the parent agent's
original authority.
11.10.41. WF-10.41 — Concrete Recursive Delegation Example
In another implementation, a primary engineering agent delegates a
code-analysis subtask to a specialist child.
The parent mandate permits at most two levels of downstream
delegation and imposes a shared tool-call budget.
The first delegated child receives a capability with one remaining
permitted delegation level.
The child proposes a further bounded handoff to a source-code
analysis agent.
The new Candidate Delegation Act is intercepted and validated against
the first child's current authority and remaining budget.
The protected system reserves the descendant's allowance and verifies
that the requested tool set remains within the permitted scope.
A new Delegation LAVR and capability are established.
The second-level child accepts the task only after the corresponding
Finality Sink verifies the capability.
If that child attempts further delegation beyond the remaining depth,
the recursion predicate fails.
Das Expires 19 April 2027 [Page 427]
Internet-Draft Protected AI Execution Finality October 2026
If the first child attempts to spawn multiple descendants whose
combined reservations exceed the shared budget, the protected budget
state prevents incompatible allocations.
If a descendant proposes code deployment, the delegation capability
does not substitute for the separately required deployment
authorization.
11.10.42. WF-10.42 — Controlled Remote-Agent Implementation
In a remote-agent embodiment, the parent agent proposes an
authenticated task to an external automated service.
The protected delegation system validates the receiving agent
identity, permitted service, data-retention conditions, task scope,
context package, tool permissions, budget, and required policy state.
The task is transmitted through an enforcement-controlled A2A gateway
or equivalent broker.
The capability may be embedded within or cryptographically associated
with the task-creation request.
The remote receiving component verifies the authorization before
creating the executable task or releasing protected task context.
If the remote service does not enforce the required scoped
restrictions, the deployment must use another controllable
enforcement arrangement or limit the claim to the boundaries actually
protected.
The architecture does not assume that sending a signed authorization
to an arbitrary third-party agent makes all of that agent's internal
execution paths non-bypassable.
11.10.43. WF-10.43 — Failure and Fail-Closed Handling
The protected system refuses an affected delegation when a mandatory
condition cannot be established.
Examples include:
(a) invalid parent authority;
(b) unauthorized delegated purpose;
(c) unknown or revoked child identity;
Das Expires 19 April 2027 [Page 428]
Internet-Draft Protected AI Execution Finality October 2026
(d) unauthorized tool scope;
(e) prohibited context disclosure;
(f) invalid memory-access scope;
(g) insufficient execution budget;
(h) exceeded recursion depth;
(i) incompatible policy epoch;
(j) invalid authority or registry authentication;
(k) unavailable protected state;
(l) failed validation-evidence commitment;
(m) missing or invalid Delegation Capability;
(n) mismatch between authorized and actual child;
(o) task or context substitution;
(p) expired capability;
(q) unauthorized duplicate capability use; or
(r) failed delegation-acceptance Finality Sink verification.
The proposed handoff remains non-effective, is denied, or is directed
through a separately authorized review procedure.
A denial record does not independently authorize child execution.
11.10.44. WF-10.44 — Crash, Retry, and Delegation Recovery
OS-1017 maintains a protected delegation outcome record.
A non-limiting state machine comprises:
PROPOSED;
STAGED;
VALIDATING;
AUTHORIZED;
Das Expires 19 April 2027 [Page 429]
Internet-Draft Protected AI Execution Finality October 2026
BUDGET_RESERVED;
INVOCATION_PENDING;
ACTIVE;
COMPLETED;
DENIED;
REVOKED;
INDETERMINATE.
Where a failure occurs before protected commitment, no corresponding
valid capability is released.
Where commitment succeeds but child activation has not been
confirmed, the recovery mechanism examines the protected delegation
and capability state.
Where a remote task may already have been accepted, the system does
not automatically create another independently authorized child task
without evaluating possible duplication.
The recovery procedure may employ authenticated task identifiers,
receiving-side status queries, idempotency records, protected
capability-consumption state, or equivalent mechanisms.
Budget reservations are released or reconciled only under the
applicable protected completion or cancellation rules.
A failed local response does not prove that the remote child was
never activated.
11.10.45. WF-10.45 — Alternative Technical Implementations
Local supervisor implementation: A protected agent runtime or
orchestration broker verifies Delegation Capabilities before enabling
subordinate workflow nodes.
Containerized implementation: Each child agent executes within a
sandbox whose permitted tools, resources, and external effects are
bounded by the delegated scope.
Hypervisor implementation: A protected host or hypervisor-controlled
service mediates subordinate virtual-machine activation and authority
transfer.
Das Expires 19 April 2027 [Page 430]
Internet-Draft Protected AI Execution Finality October 2026
Distributed-agent implementation: A protected gateway controls A2A or
equivalent remote-agent task admission and context release.
Tool-protocol implementation: An authenticated tool or connector
broker verifies the delegation capability before transferring
executable task authority to an agent-like service.
Confidential-computing implementation: A TEE or confidential workload
protects relevant mandate state, delegated authority records, and
capability-generation keys.
Hardware-assisted implementation: A secure processor, HSM, SmartNIC,
DPU, or protected gateway controls specified child-task, credential,
or communication enablement conditions.
Single-node implementation: The PED, delegation-acceptance gate,
capability mechanism, and child runtime operate within one protected
computing node.
Multi-authority implementation: Where the applicable embodiment
requires more than one authority, the delegated authorization is
validated against the defined multi-authority predicate before
capability availability.
These alternatives may provide different degrees of resistance to
privileged compromise, runtime substitution, rollback, external-agent
noncooperation, or distributed-state inconsistency.
11.10.46. WF-10.46 — PHOSITA Verification and Negative Tests
A person having ordinary skill in AI-agent orchestration, distributed
systems, access-control systems, cryptographic capabilities, trusted
execution, or protected workflow management may test the
implementation as follows.
Test 1 — Authorized delegation: A valid parent mandate and attenuated
child scope permit capability-dependent child admission.
Test 2 — Parent scope expansion: The proposed child authority exceeds
the parent's authority. Delegation is refused.
Test 3 — Tool laundering: The child is requested to use a tool
prohibited to the parent. The requested authority is withheld.
Test 4 — Memory laundering: A child is requested to access memory
unavailable to the parent. The required authorization fails.
Das Expires 19 April 2027 [Page 431]
Internet-Draft Protected AI Execution Finality October 2026
Test 5 — Context over-disclosure: The parent proposes transferring
unrelated protected data. The escrow excludes or refuses the
unauthorized content.
Test 6 — Child identity substitution: A capability issued for one
child is presented by another. Verification fails.
Test 7 — Task substitution: The delegated objective is changed after
authorization. Descriptor correspondence fails.
Test 8 — Context substitution: The transmitted context differs from
the protected commitment. The handoff is refused where exact binding
is mandatory.
Test 9 — Budget over-allocation: Concurrent child reservations exceed
a protected shared budget. The state mechanism rejects incompatible
allocations.
Test 10 — Recursion-depth violation: A child attempts further
delegation after its permitted depth is exhausted. The handoff is
refused.
Test 11 — Sibling proliferation: The parent spawns many children to
evade a common agent-count or resource limit. Protected cumulative
limits prevent unauthorized expansion.
Test 12 — Expired capability: A capability is presented outside its
required validity interval. The child admission fails.
Test 13 — Capability replay: A consumed single-use delegation
capability is presented again. Protected usage-state verification
fails.
Test 14 — Parent revocation: The parent mandate is revoked.
Descendant operations requiring that authority fail their protected
state checks.
Test 15 — Child revocation: The child registry or delegated authority
is invalidated. Further affected operations are refused.
Test 16 — ALF mismatch: The target runtime fails a mandatory
approved-logic condition. Delegation is withheld.
Test 17 — Untrusted task injection: Lower-trust content attempts to
induce a delegation beyond the authorized purpose. The required
authority or provenance predicate fails.
Das Expires 19 April 2027 [Page 432]
Internet-Draft Protected AI Execution Finality October 2026
Test 18 — Direct remote-agent call: The parent attempts to bypass the
delegation broker through an alternative uncontrolled interface. The
governed path is blocked or subjected to equivalent finality
enforcement.
Test 19 — Tool-call laundering: The parent disguises the delegation
as an ordinary tool invocation. The protected operation
classification identifies the corresponding governed delegation
boundary.
Test 20 — Unauthorized child transaction: A child with valid research
delegation attempts a payment. The payment Finality Sink refuses
effectuation absent separate authorization.
Test 21 — Return artifact injection: A child returns an artifact
containing unauthorized instructions. The applicable return-
admission gate rejects or restricts it.
Test 22 — Return data leakage: A returned artifact contains data
outside the permitted source or output scope. The protected
admission predicate fails.
Test 23 — Remote invocation timeout: The handoff response is lost
after possible task acceptance. Recovery uses protected outcome
state rather than automatically authorizing duplicate execution.
Test 24 — Budget-state outage: Required protected budget state
becomes unavailable. New affected delegations remain non-effective.
Test 25 — Parent-to-child state race: Parent authority changes
between delegation validation and child acceptance. The required
state-verification condition prevents incompatible admission.
Test 26 — Wrong Finality Sink: A capability is presented at an
unauthorized agent-acceptance interface. Verification fails.
Test 27 — Context-minimization check: The released child context is
verified to contain only the approved context items or
transformations.
Test 28 — Single-node equivalence: Delegation authority and child
acceptance operate in one protected node while maintaining the
required protected validation and finality-verification functions.
The tests may be performed using mock parent and child agents,
protected task registries, controlled handoff gateways, quota stores,
context escrow services, local process supervisors, remote task
endpoints, and fault-injection mechanisms.
Das Expires 19 April 2027 [Page 433]
Internet-Draft Protected AI Execution Finality October 2026
11.10.47. WF-10.47 — Technical Effect
The embodiment establishes a protected execution-finality dependency
between:
(a) a Parent Mandate Object;
(b) a proposed Candidate Delegation Act;
(c) mandatory interception and Non-Effective State;
(d) a canonical Delegation Intent Descriptor;
(e) authenticated child-agent identity;
(f) bounded delegated-purpose and tool authorization;
(g) context and memory minimization;
(h) protected resource-budget allocation;
(i) recursion and descendant-authority restrictions;
(j) protected authorization-state validation;
(k) required Delegation LAVR commitment;
(l) scoped non-bearer Delegation Capability availability;
(m) independent delegation-acceptance Finality Sink verification;
(n) bounded child execution;
(o) separately governed downstream effectuation; and
(p) protected admission of returned artifacts where applicable.
The architecture prevents a parent AI agent from manufacturing
broader authority through agent spawning, remote-task invocation,
tool handoff, unrestricted context transmission, shared credential
access, budget multiplication, or recursive delegation.
The protected system permits legitimate multi-agent cooperation while
maintaining the applicable parent-authority boundaries.
A Delegation Capability authorizes only its expressly bounded handoff
and does not confer unrestricted authority over subsequent
consequential operations.
Das Expires 19 April 2027 [Page 434]
Internet-Draft Protected AI Execution Finality October 2026
Computation is not authority to act.
The authority to assign a task is not authority to expand the
recipient's permissions.
Delegation of computation does not independently delegate
unrestricted execution authority.
11.11. WF-11 — Protected Autonomous Code Changes, Artifact Signing,
Software Supply-Chain Authorization, Agent-Generated Skill
Deployment, and Progressive Release Finality
11.11.1. WF-11.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture for governing software modifications,
repository operations, executable artifacts, supply-chain changes,
signing operations, and deployment instructions generated, selected,
or requested by an artificial-intelligence agent or associated
autonomous computational workload.
The system prevents a governed software change from becoming
effective at a repository merge interface, artifact-signing service,
package registry, build-finalization interface, deployment
controller, infrastructure activation interface, or other designated
release boundary without satisfaction of the applicable protected
execution-finality conditions.
An AI coding agent may generate source code, modify dependencies,
prepare build instructions, create executable packages, construct
deployment manifests, propose repository changes, or recommend
production rollouts.
Such computation does not independently authorize the corresponding
merge, signature, publication, installation, deployment, or
activation.
The proposed consequential operation is classified as a Candidate
Deployment Act and maintained in a Non-Effective State until the
applicable Protected Enforcement Domain (PED/CIED) validates the
required Supply-Chain Authority Object, performs required protected-
state operations, generates or commits protected validation evidence,
and releases or makes available a Scoped Release Capability.
The applicable release Finality Sink independently verifies that
capability against the actual operation before permitting the
authorized effect.
Das Expires 19 April 2027 [Page 435]
Internet-Draft Protected AI Execution Finality October 2026
The workflow distinguishes:
(a) generation of software or deployment instructions;
(b) preparation and validation of build or release artifacts;
(c) protected authorization of a particular consequential release
operation;
(d) use of protected signing, publishing, or activation authority;
(e) verification at the actual release Finality Sink; and
(f) subsequent software execution or deployment progression, where
independently governed.
The architecture is applicable to AI coding assistants, autonomous
software agents, DevOps agents, continuous-integration systems,
continuous-deployment systems, autonomous infrastructure controllers,
package managers, software registries, agent skill systems, and other
software supply-chain environments.
11.11.2. WF-11.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
AE-1101 — Autonomous Development Execution Environment
An AI coding agent, software-development assistant, autonomous DevOps
agent, code-generation model, build-planning system, tool-using
agent, or corresponding computational environment configured to
propose software changes.
IM-1102 — Deployment Interception Component
An enforcement-controlled interface configured to intercept a
proposed consequential software or deployment operation before the
corresponding release boundary is crossed.
HQ-1103 — Non-Effective Deployment Holding Mechanism
A controlled staging mechanism retaining a proposed deployment
operation, immutable artifact reference, pending merge request,
publication request, signing request, or deployment instruction until
required protected authorization succeeds.
DC-1104 — Candidate Deployment Act Descriptor Component
Das Expires 19 April 2027 [Page 436]
Internet-Draft Protected AI Execution Finality October 2026
A mechanism configured to construct or verify a canonical, machine-
readable representation of the proposed deployment act and its
finality-relevant context.
PED-1105 — Protected Enforcement Domain
A protected authorization component configured to authenticate the
applicable Supply-Chain Authority Object, evaluate required execution
predicates, perform protected authorization-state operations, commit
required validation evidence, and control release of deployment-
execution authority.
SA-1106 — Supply-Chain Authority Object Store
An authenticated or protected authority source maintaining the
permitted repository, branch, changed-file scope, software purpose,
workflow conditions, dependency restrictions, review requirements,
signing conditions, deployment environment, and applicable release
authority.
PS-1107 — Protected Deployment-State Store
A protected mechanism maintaining applicable policy epochs,
authorized deployment records, artifact identities, validation
commitments, nonce state, capability-usage state, release-stage
state, revocation conditions, and other mandatory authorization
information.
EV-1108 — Deployment Validation-Evidence Component
A mechanism configured to generate or commit a Deployment LAVR, ZK-
LAVR, authenticated validation record, sealed commitment, or
equivalent protected validation evidence.
CR-1109 — Scoped Release Capability Mechanism
A protected component configured to generate, derive, register,
activate, or release the scoped execution capability required by a
governed release operation.
KS-1110 — Protected Signing or Activation-Key Component
An optional HSM, secure enclave, protected key service, trusted
controller, or equivalent protected component maintaining production
signing, publication, or activation authority.
FS-1111 — Release Finality Sink
Das Expires 19 April 2027 [Page 437]
Internet-Draft Protected AI Execution Finality October 2026
An enforcement-controlled repository manager, merge controller,
signing service, package registry, build-finalization interface,
deployment orchestrator, infrastructure controller, or equivalent
technical boundary that verifies required release authority before
effectuation.
RM-1112 — Runtime and Rollout Monitoring Component
An optional component configured to provide required deployment
telemetry, runtime behavioral measurements, anomaly evidence,
rollout-stage status, and policy-state information.
OS-1113 — Deployment Outcome-State Component
A protected mechanism maintaining completed, denied, staged,
reserved, interrupted, revoked, rolled-back, or indeterminate
deployment-effectuation information.
SC-1114 — Release-State Consistency Component
A mechanism configured to verify required correspondence among the
validated artifact, authorized deployment stage, protected policy
epoch, capability state, target environment, and actual release
operation.
The components may be implemented within one node, across multiple
authenticated services, within a protected controller, through
software-isolated components, or using hardware-rooted enforcement.
The PED, Finality Gate, and Finality Sink perform distinguishable
functions but need not comprise physically separate devices where the
applicable protected verification relationships are maintained.
11.11.3. WF-11.3 — Establishment of the Software Supply-Chain Trust
Boundary
Before governed software modifications are permitted to become
effective, the system establishes a trust boundary between AE-1101
and the repository, signing, publication, and deployment interfaces
controlled by FS-1111.
The agent may prepare and submit software changes but does not
independently possess unrestricted authority to:
(a) merge into a protected repository branch;
(b) alter protected release policies;
Das Expires 19 April 2027 [Page 438]
Internet-Draft Protected AI Execution Finality October 2026
(c) use a production artifact-signing key;
(d) publish to a protected package registry;
(e) activate an unapproved executable skill;
(f) replace approved build or deployment instructions;
(g) promote a container image into a protected environment;
(h) modify infrastructure resources outside the applicable authority
scope;
(i) override protected test or review requirements; or
(j) invoke an alternative release path that bypasses the designated
finality controls.
In one implementation, an AI agent operates within a sandboxed
development environment that has permission to create local code
changes but lacks direct authority over protected production release
interfaces.
The agent submits proposed consequential operations to IM-1102.
A non-authoritative intermediary may transport or prepare a release
request, but cannot independently create the protected release
capability.
11.11.4. WF-11.4 — Identification of Governed Release Boundaries
The system identifies the operations that are governed as
consequential release events.
Non-limiting boundaries include:
(a) protected source-code branch merge;
(b) repository reference or release-tag mutation;
(c) signing of an executable artifact;
(d) signing of a production container image;
(e) admission of a package into a protected registry;
(f) publication of a software release;
Das Expires 19 April 2027 [Page 439]
Internet-Draft Protected AI Execution Finality October 2026
(g) promotion of an artifact between deployment environments;
(h) application of an infrastructure-as-code modification;
(i) activation of a production workload;
(j) installation or activation of an AI-agent skill;
(k) modification of production CI/CD instructions;
(l) release of an update to a protected device or service; and
(m) execution of a production rollback where the rollback itself is
governed.
Each boundary is associated with a release Finality Sink or another
protected finality-verification mechanism.
The system distinguishes multiple release boundaries when the
corresponding effects are separate.
For example, authorization to merge source code does not
automatically authorize production artifact signing or deployment.
11.11.5. WF-11.5 — Mandatory Interception and Release-Path Coverage
The system configures each governed release path so that the relevant
consequential effect depends upon the required finality verification.
In a repository implementation, this may include protected branch
controls and a repository merge service accepting only release
operations that pass the applicable capability-verification
procedure.
In an artifact-signing implementation, the signing key remains
inaccessible to the untrusted agent and unauthorized CI/CD
components.
In a deployment implementation, the production deployment controller
accepts only operations satisfying the applicable protected release-
capability conditions.
A build pipeline that merely calls a validation script is
insufficient to establish non-bypassability if the agent can invoke a
separate signing or deployment interface that performs the same
protected effect without verification.
Das Expires 19 April 2027 [Page 440]
Internet-Draft Protected AI Execution Finality October 2026
The actual implementation therefore identifies and controls all
agent-accessible release paths capable of producing the governed
effect.
Non-bypassability is evaluated against the specified threat model and
the interfaces actually controlled by the implementation.
11.11.6. WF-11.6 — Generation of the Candidate Deployment Act
AE-1101 receives an authorized development task or proposed
operational objective.
The agent may generate:
(a) a source-code modification;
(b) a dependency update;
(c) a build-script change;
(d) a CI/CD configuration modification;
(e) a deployment manifest;
(f) an infrastructure-as-code modification;
(g) a software package or executable artifact;
(h) an agent-generated skill or plugin;
(i) a container image;
(j) a production release instruction; or
(k) another proposed software supply-chain operation.
The corresponding consequential request is classified as Candidate
Deployment Act CDA-1115.
Generation of CDA-1115 does not independently authorize the act to
produce a protected repository, signing, publication, or deployment
effect.
11.11.7. WF-11.7 — Interception and Non-Effective Staging
IM-1102 intercepts CDA-1115 before the governed release effect
occurs.
Das Expires 19 April 2027 [Page 441]
Internet-Draft Protected AI Execution Finality October 2026
The proposed operation is placed within HQ-1103.
An illustrative staging record comprises:
operation_id;
requesting_agent_id;
repository_id;
branch_id;
proposed_commit_reference;
artifact_reference;
requested_release_operation;
target_environment;
requested_finality_sink;
policy_epoch;
created_at;
status = NON_EFFECTIVE.
The system may store the corresponding source change, build output,
or artifact bytes in controlled temporary storage while retaining an
immutable or authenticated reference for authorization.
The staging mechanism prevents the proposed operation from reaching
the protected release interface until the required authorization
conditions are established.
A locally successful build or test does not itself advance the
Candidate Deployment Act into an effective release state.
11.11.8. WF-11.8 — Construction of the Candidate Deployment Act
Descriptor
DC-1104 constructs a machine-readable Candidate Deployment Act
Descriptor identifying the effectuation-relevant attributes of CDA-
1115.
A non-limiting descriptor comprises:
Das Expires 19 April 2027 [Page 442]
Internet-Draft Protected AI Execution Finality October 2026
operation_id;
requesting_agent_identity;
repository_identity;
branch_identity;
commit_digest;
diff_digest;
changed_file_classes;
dependency_changes;
CI_CD_changes;
build_script_changes;
infrastructure_resource_changes;
secret_handling_changes;
network_egress_changes;
privileged_API_changes;
test_status;
scanner_status;
review_state;
artifact_digest;
package_identity;
release_environment;
deployment_target;
agent_identity;
approver_identity;
authorized_purpose_reference;
Das Expires 19 April 2027 [Page 443]
Internet-Draft Protected AI Execution Finality October 2026
policy_epoch;
revocation_epoch;
nonce;
expiry;
release_stage;
finality_sink_identity.
The particular Authority Object and specified embodiment determine
which fields are mandatory.
The descriptor distinguishes the proposed software change from the
authority to make that change effective.
11.11.9. WF-11.9 — Deterministic Descriptor Encoding
In a cryptographic implementation, the descriptor is encoded using a
defined deterministic serialization procedure.
An illustrative representation is:
Ddeploy = Canon_v(REPO, BRANCH, COMMIT, DIFF, ARTIFACT, OP, TARGET,
ENV, X, EPOCH, SINK)
where:
Ddeploy denotes the canonical deployment descriptor;
Canon_v denotes deterministic canonical encoding under version v;
REPO denotes the authenticated repository identity;
BRANCH denotes the affected repository branch;
COMMIT denotes the applicable commit digest;
DIFF denotes the required source-change digest;
ARTIFACT denotes the artifact or package identity;
OP denotes the requested consequential operation;
TARGET denotes the intended deployment or release target;
Das Expires 19 April 2027 [Page 444]
Internet-Draft Protected AI Execution Finality October 2026
ENV denotes the release environment;
X denotes applicable runtime, review, and validation context;
EPOCH denotes the applicable authorization-state version; and
SINK denotes the designated release Finality Sink.
An illustrative descriptor commitment is:
hDeploy = H("DAS-DEPLOY-v1" || Encode(Ddeploy))
where H is a cryptographic hash function and the quoted label
identifies the illustrative domain of the commitment.
The encoder uses unambiguous field representations and consistent
digest interpretation.
The same encoding rules are applied when FS-1111 reconstructs or
verifies the actual release operation.
The particular encoding and hash algorithm are implementation choices
rather than mandatory requirements of every embodiment.
11.11.10. WF-11.10 — Acquisition of the Supply-Chain Authority Object
PED-1105 obtains the applicable Supply-Chain Authority Object from
SA-1106.
The Authority Object may identify:
(a) authorized repositories and branches;
(b) permitted source-code paths;
(c) allowed dependency classes;
(d) permitted build and deployment operations;
(e) authorized software-development purpose;
(f) required ALF or approved workflow;
(g) required test and scanner results;
(h) code-review and human-approval requirements;
(i) protected signing requirements;
Das Expires 19 April 2027 [Page 445]
Internet-Draft Protected AI Execution Finality October 2026
(j) permitted release environments;
(k) authorized deployment targets;
(l) release time windows;
(m) permitted rollback procedures;
(n) policy epoch and revocation requirements; and
(o) applicable Finality Sink identities.
PED-1105 verifies the authenticity, applicability, validity, and
required current authorization state of the Authority Object.
An agent-generated assertion that a release is safe or approved does
not independently establish protected release authority.
11.11.11. WF-11.11 — Authorized Development Purpose Validation
PED-1105 evaluates whether CDA-1115 remains within the authorized
development or deployment purpose.
Where applicable, the Algorithmic Intent Fingerprint (AIF) represents
the approved software-development objective and its permitted
operating scope.
The validation compares the proposed software change with the
authorized task.
For example, authority to repair a logging defect does not
automatically authorize the agent to modify production credential
controls or network security policies.
The proposed operation may satisfy the authorized intent condition
through exact correspondence or a narrower permitted scope, according
to the applicable AIF matching rules.
An unauthorized widening of the task causes the corresponding
protected purpose predicate to fail.
11.11.12. WF-11.12 — Approved Logic and Workflow Validation
Where required, PED-1105 validates the applicable Algorithmic Logic
Fingerprint (ALF).
The ALF may represent an approved:
Das Expires 19 April 2027 [Page 446]
Internet-Draft Protected AI Execution Finality October 2026
(a) code-generation workflow;
(b) source-review workflow;
(c) test pipeline;
(d) build pipeline;
(e) dependency-resolution process;
(f) software-packaging process;
(g) signing workflow;
(h) package-publication process; or
(i) deployment process.
The PED verifies that the relevant executing workflow corresponds to
the approved logic or configuration under the applicable authority
rules.
A change to a protected build or review pipeline may require separate
authorization because the modification can change the technical
procedure through which future artifacts are approved.
ALF validation is a required authorization predicate only when
specified by the applicable Authority Object or embodiment.
It does not independently replace release capability issuance and
Finality Sink verification.
11.11.13. WF-11.13 — Runtime Behavioral and Provenance Validation
Where required, PED-1105 evaluates a Runtime Behavioral Descriptor
(RBD) associated with the development operation.
The RBD may record:
(a) source files accessed;
(b) tools invoked;
(c) build commands executed;
(d) dependencies introduced;
(e) external repositories consulted;
Das Expires 19 April 2027 [Page 447]
Internet-Draft Protected AI Execution Finality October 2026
(f) retrieved source material;
(g) test commands performed;
(h) scanners executed;
(i) review events;
(j) CI/CD changes;
(k) privileged operations requested;
(l) external content sources influencing code generation; and
(m) relevant runtime deviations.
The protected system may additionally evaluate provenance or taint
information associated with code generated from untrusted external
inputs.
Untrusted retrieved content does not independently authorize changes
to deployment policy, protected signing configuration, production
infrastructure, or privileged execution scope.
A required provenance failure prevents the corresponding release
capability from being made available.
11.11.14. WF-11.14 — Changed-File and Dependency-Scope Validation
PED-1105 compares the proposed change against the permitted file and
dependency scope.
The evaluation may consider:
(a) modified repository paths;
(b) newly created executable files;
(c) deleted security controls;
(d) modified dependency manifests;
(e) new package sources;
(f) modified lockfiles;
(g) executable dependency-installation hooks;
Das Expires 19 April 2027 [Page 448]
Internet-Draft Protected AI Execution Finality October 2026
(h) build-time scripts;
(i) privileged library usage; and
(j) changes to software integrity or verification logic.
Where exact changed-file restrictions are required, the validated
descriptor binds the relevant file identities or change digest.
A modification outside the permitted authority scope is rejected or
subjected to separately authorized review.
The system does not assume that a change remains acceptable merely
because ordinary compilation or unit tests succeed.
11.11.15. WF-11.15 — Credential, Privilege, and Network-Egress Change
Validation
PED-1105 evaluates whether the proposed modification changes
protected operational permissions.
Applicable changes may include:
(a) adding credential-reading logic;
(b) changing secret-management interfaces;
(c) introducing credential export paths;
(d) modifying authentication controls;
(e) widening operating-system privileges;
(f) changing production network destinations;
(g) creating new outbound communication capabilities;
(h) modifying firewall or egress rules;
(i) changing privileged APIs;
(j) changing deployment-service identities; and
(k) replacing protected release-verification logic.
Where such changes fall outside the authorized scope, the protected
system withholds the required release capability.
Das Expires 19 April 2027 [Page 449]
Internet-Draft Protected AI Execution Finality October 2026
An agent cannot manufacture permission for its own privileged code
change merely by editing the ordinary policy file that would
otherwise reject the operation.
11.11.16. WF-11.16 — Test, Scan, Review, and Approval Validation
The protected authority evaluates the test, scanner, review, and
approval results required by the applicable Supply-Chain Authority
Object.
Such requirements may include:
(a) unit-test completion;
(b) integration-test completion;
(c) static analysis;
(d) dynamic analysis;
(e) dependency vulnerability scanning;
(f) secret detection;
(g) software bill of materials verification;
(h) artifact provenance validation;
(i) build attestation;
(j) required code review; and
(k) authenticated human approval.
The PED determines whether each mandatory requirement has been
satisfied for the actual Candidate Deployment Act.
A scanner result associated with an earlier commit is not treated as
valid for a materially different artifact when exact artifact
correspondence is required.
An approval for one repository, change, or deployment target does not
authorize a different operation outside the approved scope.
11.11.17. WF-11.17 — Protected Release Authorization Predicate
PED-1105 evaluates the required release predicates.
Das Expires 19 April 2027 [Page 450]
Internet-Draft Protected AI Execution Finality October 2026
For an illustrative conjunctive authorization policy:
Vdeploy = Ppurpose AND Pworkflow AND Pchange AND Partifact AND
Prelease AND Pstate
where:
Vdeploy denotes the protected deployment-validation result;
Ppurpose verifies authorized development purpose;
Pworkflow verifies the applicable approved ALF or workflow;
Pchange verifies the permitted code, dependency, configuration,
privilege, and infrastructure modifications;
Partifact verifies the applicable source, build, and artifact
identity;
Prelease verifies required tests, scans, reviews, approvals, target,
and release scope; and
Pstate verifies required policy, revocation, freshness, and
protected-state conditions.
Additional predicates may be imposed by the applicable Authority
Object.
Where approved alternative or threshold conditions are specified, the
protected system evaluates those according to the authorized
combination rules rather than requiring literal conjunction of all
possible predicates.
A failure of any mandatory predicate prevents successful release
authorization.
11.11.18. WF-11.18 — Protected Deployment-State Reservation
Following successful predicate validation, PED-1105 performs the
protected-state operation required for CDA-1115.
The operation may comprise:
(a) reserving the authorization for a particular release act;
(b) consuming or registering an authorization nonce;
(c) advancing a protected release counter;
Das Expires 19 April 2027 [Page 451]
Internet-Draft Protected AI Execution Finality October 2026
(d) recording the validated artifact digest;
(e) checking the current policy epoch;
(f) registering the approved deployment stage;
(g) consuming a single-use release grant;
(h) verifying non-revocation; or
(i) performing another required protected authorization transition.
For a single-use release grant, an illustrative transition is:
AVAILABLE → RESERVED(operation_id, artifact_digest, state_version)
The transition is performed using protected transactional storage, a
secure compare-and-update mechanism, a hardware-protected counter, or
an equivalent state mechanism.
Where multiple requests compete for one restricted release grant, the
protected mechanism prevents unauthorized concurrent consumption.
If the required state transition cannot be established consistently,
the release capability is withheld.
11.11.19. WF-11.19 — Deployment Validation-Evidence Commitment
After successful authorization and in coordination with the
protected-state transition, EV-1108 generates or commits the
applicable protected validation evidence.
The evidence may comprise a Deployment LAVR, ZK-LAVR, sealed
validation record, authenticated commitment, or equivalent protected
representation.
An illustrative evidence record contains:
receipt_id;
candidate_deployment_act_id;
deployment_descriptor_digest;
repository_identity;
commit_digest;
Das Expires 19 April 2027 [Page 452]
Internet-Draft Protected AI Execution Finality October 2026
artifact_digest;
authority_object_reference;
validated_predicate_reference;
test_and_review_state_reference;
protected_state_transition;
authorized_release_environment;
policy_epoch;
nonce;
finality_sink_id;
decision;
protected_authentication.
Where the applicable embodiment requires pre-effectuation evidence
commitment, the protected commitment is completed before, or
atomically with, capability availability.
Ordinary CI/CD audit logs created after a release do not
independently substitute for this required protected authorization
dependency.
11.11.20. WF-11.20 — Privacy-Preserving Deployment Validation Variant
Where deployment rules, enterprise source policies, private scanner
findings, proprietary workflow measurements, or protected review
criteria must remain confidential, the PED/CIED may employ a ZK-LAVR.
In an embodiment using an actual zero-knowledge proof construction,
the validation evidence may establish satisfaction of defined release
predicates without exposing specified confidential predicate inputs.
The protected release capability remains conditional upon the proof,
commitment, and required authorization state being valid.
A ZK-LAVR is not itself an unrestricted release credential.
The precise zero-knowledge guarantee depends upon the implemented
proof system and its established security assumptions.
Das Expires 19 April 2027 [Page 453]
Internet-Draft Protected AI Execution Finality October 2026
Where a hybrid attestation mechanism is used instead, the system
claims only the confidentiality and verification properties actually
provided by that implementation.
11.11.21. WF-11.21 — Protected Deployment-Finality Transaction
The PED coordinates the required validation, protected-state
handling, evidence commitment, and capability-availability
conditions.
An illustrative protected finality transaction is:
(Snext, Rdeploy, Ready) = CommitDeployment(Ddeploy, A, Scurrent, F)
where:
Snext denotes the successfully committed protected deployment state;
Rdeploy denotes the protected deployment-validation evidence;
Ready denotes the protected indication that required release
prerequisites are satisfied;
Ddeploy denotes the validated Candidate Deployment Act Descriptor;
A denotes the authenticated Supply-Chain Authority Object;
Scurrent denotes the protected authorization state before commitment;
and
F denotes the designated release Finality Sink.
The transaction does not produce an externally usable release
capability if a mandatory protected-state or evidence-commitment
operation remains incomplete.
The protected transaction may be implemented using transactional
state, an HSM-controlled authorization procedure, sealed storage,
authenticated release-state machinery, or equivalent protected
mechanisms.
This transaction does not presume that an arbitrary external package
registry or deployment target participates in one globally atomic
database transaction.
Das Expires 19 April 2027 [Page 454]
Internet-Draft Protected AI Execution Finality October 2026
11.11.22. WF-11.22 — Scoped Release Capability Generation
After successful completion of the required protected deployment-
finality transaction, CR-1109 generates, registers, or makes
available a Scoped Release Capability.
In an illustrative cryptographic implementation:
Crelease = Sign_skPED(Encode(hDeploy, hR, Repo, Commit, Artifact,
Target, Env, F, Epoch, Nonce, Expiry, CID))
where:
Crelease denotes the Scoped Release Capability;
Sign_skPED denotes signature generation using a signing key
controlled by the PED;
hDeploy denotes the deployment descriptor digest;
hR denotes the committed deployment-validation evidence digest;
Repo denotes the authorized repository;
Commit denotes the validated commit identity;
Artifact denotes the authorized artifact identity;
Target denotes the authorized deployment target;
Env denotes the authorized release environment;
F denotes the applicable release Finality Sink;
Epoch denotes the required policy or authorization epoch;
Nonce denotes the required freshness value;
Expiry denotes the capability validity limit; and
CID denotes the capability identifier.
The particular artifact representation, cryptographic signature
scheme, encoding format, and key substrate depend upon the selected
implementation.
The capability is not treated as non-bearer merely because it is
cryptographically signed.
Das Expires 19 April 2027 [Page 455]
Internet-Draft Protected AI Execution Finality October 2026
The receiving release Finality Sink enforces the required artifact,
operation, environment, scope, state, and consumption restrictions
before permitting effectuation.
11.11.23. WF-11.23 — Artifact and Commit Binding
in the implementation described by enforcement point 44, the Scoped
Release Capability is bound to:
(a) commit digest;
(b) artifact digest;
(c) repository identity;
(d) branch identity;
(e) deployment target;
(f) release environment;
(g) policy epoch;
(h) nonce; and
(i) expiry.
The Finality Sink obtains the actual repository, commit, artifact,
destination, and environment involved in the requested consequential
operation.
The protected verification procedure compares those values against
the capability's mandatory bindings.
Where exact artifact correspondence is required, substitution of a
different artifact digest causes verification failure.
Where the actual deployment target differs from the authorized
target, the release is refused unless renewed authorization permits
the changed operation.
The authorization is therefore associated with the artifact and
effectuation operation actually presented, rather than merely with
the agent's earlier statement that a deployment was approved.
Das Expires 19 April 2027 [Page 456]
Internet-Draft Protected AI Execution Finality October 2026
11.11.24. WF-11.24 — Binding Source Changes to Built Artifacts
In an implementation involving separate source and build stages, the
system maintains a verifiable relationship between the authorized
source change and the artifact submitted for signing or deployment.
The relationship may use:
(a) an authenticated source commit;
(b) an approved build definition;
(c) an artifact digest;
(d) a build-attestation record;
(e) a signed provenance statement;
(f) a protected source-to-artifact mapping; or
(g) another machine-verifiable build identity mechanism.
Where a claim or authority condition requires correspondence between
the validated commit and the deployed artifact, the protected system
verifies the required relationship.
The presence of an artifact digest alone does not establish that the
artifact was produced from an approved source commit.
If the build result changes materially, the previous authorization is
insufficient where the required artifact binding no longer matches.
11.11.25. WF-11.25 — Protected Artifact-Signing and Publication Keys
In the stronger hardware-protected embodiment corresponding to
enforcement point 45, KS-1110 retains one or more protected release
keys.
Such keys may include:
(a) a production artifact-signing key;
(b) a package-publication key;
(c) a protected container-signing key;
(d) an artifact-activation key; or
Das Expires 19 April 2027 [Page 457]
Internet-Draft Protected AI Execution Finality October 2026
(e) a deployment-enablement key.
KS-1110 may comprise a hardware security module, secure enclave, or
equivalent protected key-control environment satisfying the
applicable claim limitations.
The untrusted coding agent and ordinary CI/CD controller do not
receive unrestricted access to the protected release key.
A signing or activation request is processed only after the required
corresponding Scoped Release Capability has been verified.
The protected component validates the requested key usage, artifact
identity, operation scope, release context, and required
authorization state.
A key existing within an HSM does not by itself establish deployment-
finality security. The required capability-dependent key-use
restriction must actually be enforced.
11.11.26. WF-11.26 — Hardware-Latched Release Procedure
A hardware-latched release implementation may operate as follows.
First, the AI agent generates a proposed artifact or deployment
instruction.
Second, the deployment interception component holds the corresponding
release request.
Third, PED-1105 validates the Candidate Deployment Act against its
applicable Supply-Chain Authority Object.
Fourth, the PED completes the required protected-state and evidence-
commitment operations.
Fifth, CR-1109 makes available the corresponding Scoped Release
Capability.
Sixth, KS-1110 or the designated release-verification component
authenticates the capability and verifies the required artifact, key-
use, environment, policy, freshness, and Finality Sink bindings.
Seventh, the protected key operation is enabled only for the
validated release act.
Eighth, the artifact-signing or deployment-enablement operation
proceeds within the permitted scope.
Das Expires 19 April 2027 [Page 458]
Internet-Draft Protected AI Execution Finality October 2026
If the required authorization or capability verification fails, the
protected signing or activation key remains unavailable for the
requested operation.
In a non-exportable-key implementation, the protected module may
perform the approved signing operation without exposing the
underlying private key.
The architecture thereby prevents the ordinary CI/CD controller from
treating possession of a key reference or signing-service endpoint as
unrestricted production release authority.
11.11.27. WF-11.27 — Independent Verification at the Release Finality
Sink
FS-1111 obtains the actual consequential release request and the
corresponding Scoped Release Capability or authenticated capability
reference.
Before effectuation, the Finality Sink verifies:
(a) capability authenticity;
(b) required deployment descriptor correspondence;
(c) repository and branch identity;
(d) commit digest;
(e) artifact digest;
(f) requested release-operation class;
(g) actual deployment target;
(h) release environment;
(i) designated Finality Sink identity;
(j) required policy and revocation state;
(k) nonce and expiry conditions;
(l) required validation-evidence commitment; and
(m) applicable capability-usage or consumption state.
An illustrative verification predicate is:
Das Expires 19 April 2027 [Page 459]
Internet-Draft Protected AI Execution Finality October 2026
PermitRelease = Auth(C) AND Match(C,Dactual) AND
ArtifactValid(C,Aactual) AND TargetValid(C,Tactual) AND
StateValid(C,S) AND SinkValid(C,F)
where:
C denotes the Scoped Release Capability;
Dactual denotes the actual deployment operation descriptor;
Aactual denotes the actual artifact;
Tactual denotes the actual deployment target;
S denotes the required protected authorization state; and
F denotes the release Finality Sink.
The governed release operation proceeds only when all mandatory
verification predicates succeed.
The Finality Sink does not rely solely upon an upstream CI/CD system
reporting that tests, reviews, or approvals were successful.
11.11.28. WF-11.28 — Finality-Specific Release Operations
The release Finality Sink may be implemented at different
consequential boundaries.
Repository merge: The controlled merge interface verifies the
capability before updating the protected repository reference.
Artifact signing: The signing service verifies the capability before
producing the protected signature.
Package publication: The package registry admission interface
verifies the capability before making the package available through
the governed registry.
Build finalization: The protected build interface verifies applicable
release authority before admitting a build result into the designated
authoritative artifact state.
Production deployment: The deployment controller verifies the
capability before applying the protected workload change.
Das Expires 19 April 2027 [Page 460]
Internet-Draft Protected AI Execution Finality October 2026
Infrastructure activation: The infrastructure controller verifies the
applicable capability before applying the governed configuration or
resource mutation.
The authorization and effectuation semantics depend upon the selected
boundary.
A successful repository merge does not automatically establish
authorization for later production deployment.
11.11.29. WF-11.29 — Agent-Generated Skill and Plugin Deployment
in the implementation described by enforcement point 46, CDA-1115
comprises a proposed installation, activation, publication, or
execution enablement of an agent-generated skill, plugin, tool
package, script, executable artifact, or associated agent capability.
An AI agent may generate a skill containing:
(a) executable instructions;
(b) a tool manifest;
(c) new API integrations;
(d) filesystem access requirements;
(e) credential-use requirements;
(f) network destinations;
(g) dependency changes;
(h) runtime execution permissions; or
(i) modifications to the approved agent tool graph.
The proposed skill remains non-effective at its governed installation
or activation boundary pending protected authorization.
PED-1105 validates the skill against:
(a) the authorized purpose;
(b) approved tool graph or ALF;
(c) dependency changes;
Das Expires 19 April 2027 [Page 461]
Internet-Draft Protected AI Execution Finality October 2026
(d) privileged API use;
(e) permitted execution scope; and
(f) other applicable authority predicates.
A skill-generated request to increase its own permissions does not
independently authorize the requested scope expansion.
The protected system distinguishes permission to generate a skill
package from permission to activate the skill within a particular
agent execution environment.
11.11.30. WF-11.30 — Skill Installation and Activation Finality
In one implementation, the protected agent runtime maintains a skill
installation or activation interface controlled by a designated
Finality Sink.
The AI agent produces a skill package and corresponding manifest.
The proposed installation or activation request is intercepted and
staged.
The system constructs a Candidate Deployment Act Descriptor
identifying the skill artifact, requesting agent, package digest,
permitted tool graph, dependency set, requested permissions, target
agent runtime, applicable policy epoch, and activation Finality Sink.
PED-1105 validates the applicable Supply-Chain Authority Object and
mandatory runtime predicates.
Upon successful protected validation, the required deployment
evidence is committed and a Scoped Release Capability is issued or
made available.
The activation Finality Sink verifies the capability against the
actual skill package and requested permissions.
The protected interface permits installation or activation only when
the required verification succeeds.
If the skill requests a privileged API, dependency, destination, or
tool permission outside the authorized scope, the operation remains
non-effective unless separately authorized.
Das Expires 19 April 2027 [Page 462]
Internet-Draft Protected AI Execution Finality October 2026
Where activation changes the agent's approved runtime configuration,
the corresponding self-modification controls described in WF-09 may
also apply.
11.11.31. WF-11.31 — Separation of Skill Activation from Later Tool
Execution
Successful installation or activation of an approved skill does not
automatically authorize every consequential operation later requested
through that skill.
The skill may generate a subsequent Candidate Act requiring network
access, credential application, file mutation, database commitment,
payment execution, or another protected effectuation operation.
Each separately governed downstream act remains subject to the
corresponding protected authorization and Finality Sink verification.
The Scoped Release Capability used to activate the skill is not
automatically reusable as a general Sandbox Egress Capability or
credential-effectuation capability.
This prevents software-installation authorization from being
converted into unrestricted downstream operational authority.
11.11.32. WF-11.32 — Progressive Deployment and Stage-Specific
Authority
in the implementation described by enforcement point 47, a deployment
comprises multiple governed release stages.
Non-limiting stages include:
(a) development build;
(b) protected test environment;
(c) staging environment;
(d) canary release;
(e) limited production rollout;
(f) progressive rollout;
(g) blue-green deployment;
(h) full production release; and
Das Expires 19 April 2027 [Page 463]
Internet-Draft Protected AI Execution Finality October 2026
(i) authorized rollback or recovery.
The PED evaluates the authority applicable to each governed stage.
A capability for one stage does not automatically authorize
progression into another independently governed stage.
A stage-specific capability may bind:
deployment_id;
artifact_digest;
stage_id;
source_environment;
target_environment;
permitted_rollout_scope;
policy_epoch;
runtime_state_reference;
nonce;
expiry;
finality_sink_id.
The corresponding stage Finality Sink verifies the applicable
capability before enabling that deployment stage.
11.11.33. WF-11.33 — Stage-Associated Micro-LAVRs and Rollout
Capabilities
For a staged release, the PED may generate stage-associated protected
validation evidence, including micro-LAVRs.
An illustrative stage record comprises:
deployment_id;
stage_id;
artifact_digest;
Das Expires 19 April 2027 [Page 464]
Internet-Draft Protected AI Execution Finality October 2026
prior_stage_reference;
stage_validation_result;
runtime_telemetry_reference;
policy_epoch;
protected_state_version;
next_stage_scope;
finality_sink_id.
After successful validation of the applicable release conditions, the
PED issues or makes available a corresponding scoped rollout
capability.
The deployment controller verifies the capability before advancing to
the next protected rollout stage.
Where the applicable embodiment requires receipt-chain continuity,
the next-stage authorization is associated with the protected
evidence and state of the preceding stage.
The capability does not automatically authorize arbitrary expansion
of deployment scope.
11.11.34. WF-11.34 — Runtime Drift and Rollout Interruption
RM-1112 obtains relevant runtime telemetry and behavioral evidence
during a staged deployment.
Such evidence may include:
(a) service failure rates;
(b) security-policy violations;
(c) unauthorized network behavior;
(d) abnormal credential use;
(e) unexpected privileged operations;
(f) changed deployment configuration;
(g) artifact-integrity failures;
Das Expires 19 April 2027 [Page 465]
Internet-Draft Protected AI Execution Finality October 2026
(h) runtime behavioral deviation;
(i) revocation events; and
(j) applicable protected policy-state changes.
The PED evaluates telemetry, RBD information, policy state, and
required anomaly conditions.
Where a mandatory runtime-drift, policy-validity, or revocation
condition fails, the PED withholds the subsequent scoped rollout
capability.
The next governed stage remains non-effective.
Withholding the next capability prevents further protected deployment
progression, but does not automatically reverse deployment effects
already completed in earlier stages.
Where rollback is required, rollback is performed through its
applicable separately authorized procedure.
11.11.35. WF-11.35 — Rollout Progression Predicate
For a staged deployment, an illustrative progression predicate is:
PermitStage(i+1) = StageValid(i) AND ArtifactValid(i+1) AND
TelemetryValid(i) AND PolicyValid(i+1) AND AuthorityValid(i+1)
where:
PermitStage(i+1) denotes authorization to progress to the next
governed stage;
StageValid(i) verifies the required completion or authorization state
of the prior stage;
ArtifactValid(i+1) verifies the artifact identity applicable to the
requested stage;
TelemetryValid(i) verifies the runtime conditions required from the
preceding stage;
PolicyValid(i+1) verifies the applicable current policy and
revocation conditions; and
AuthorityValid(i+1) verifies the required protected authorization for
the next stage.
Das Expires 19 April 2027 [Page 466]
Internet-Draft Protected AI Execution Finality October 2026
Where additional conditions are mandatory, they are incorporated into
the authorization procedure.
If the predicate fails, the corresponding rollout capability is
withheld.
The deployment controller cannot treat a previous stage's successful
release as unrestricted authority for all later stages.
11.11.36. WF-11.36 — Protected Capability Consumption and Duplicate-
Release Prevention
Where a release capability permits only one governed effectuation,
FS-1111 performs or coordinates the required protected capability-
consumption operation.
A representative capability-state record comprises:
capability_id;
deployment_id;
artifact_digest;
authorized_release_sink;
release_stage;
remaining_uses;
state_version;
status.
The system verifies that the capability remains valid and within its
authorized usage allowance immediately before effectuation.
For a single-use capability, the protected mechanism prevents a
second incompatible execution from independently consuming the same
grant.
Where the authorized release permits bounded multiple uses, the
applicable usage restrictions are enforced through protected state.
A consumed capability does not authorize another release contrary to
its permitted scope.
Das Expires 19 April 2027 [Page 467]
Internet-Draft Protected AI Execution Finality October 2026
The capability-consumption procedure does not itself guarantee that
every remote deployment has completed successfully or exactly once.
11.11.37. WF-11.37 — Policy Updates, Revocation, and Artifact
Invalidation
During development or deployment, the applicable authority conditions
may change.
Non-limiting events include:
(a) revocation of a software release approval;
(b) invalidation of an artifact signature;
(c) supersession of a permitted policy epoch;
(d) discovery of a prohibited dependency;
(e) withdrawal of an authorized deployment environment;
(f) compromise of a signing credential;
(g) revocation of an agent's development authority; or
(h) detection of unauthorized runtime behavior.
The PED updates or consults the applicable protected authorization
state.
Where current authorization verification is required, a capability
associated with invalid or superseded state cannot authorize further
effectuation.
Revocation of future deployment authority does not automatically undo
an already completed repository merge, publication, or production
state change.
Any resulting withdrawal, rollback, or recovery operation is governed
according to its own effectuation requirements.
11.11.38. WF-11.38 — Time-of-Check and Time-of-Use Protection
The architecture maintains the required correspondence between the
validated deployment act and the operation actually presented at the
Finality Sink.
Potential substitutions include:
Das Expires 19 April 2027 [Page 468]
Internet-Draft Protected AI Execution Finality October 2026
(a) replacing the source commit;
(b) altering the built artifact;
(c) changing the target repository;
(d) changing the destination branch;
(e) replacing a container image;
(f) changing the deployment environment;
(g) modifying a package manifest;
(h) changing the skill permissions;
(i) substituting a signing-key identifier;
(j) changing the release stage; or
(k) using a capability after an incompatible policy-state update.
Where a required field differs, the prior capability is rejected
unless the modification falls within an expressly authorized bounded
scope.
The Finality Sink obtains the actual effectuation-relevant attributes
through an authenticated or otherwise controlled representation.
The system does not rely solely upon a release description supplied
by the requesting agent.
11.11.39. WF-11.39 — Crash, Timeout, and Deployment Recovery
The system distinguishes failures occurring at different stages of
the protected deployment-finality procedure.
Failure before validation commitment: No valid release capability
becomes available for an incomplete mandatory authorization
transaction.
Failure after protected commitment but before capability delivery:
The protected system consults committed authorization and capability
state before restoring, reissuing, or retiring the associated
capability.
Das Expires 19 April 2027 [Page 469]
Internet-Draft Protected AI Execution Finality October 2026
Failure before a protected signing operation: The system determines
whether the signing capability remains valid and whether the
protected key operation has occurred.
Failure after possible signing or publication: The corresponding
outcome may be indeterminate until suitable authoritative completion
evidence is obtained.
Failure after deployment initiation: The system distinguishes an
operation known not to have taken effect from an operation that may
already have changed a production environment.
The protected outcome-state component may maintain:
PENDING;
VALIDATING;
AUTHORIZED;
RESERVED;
SIGNING_IN_PROGRESS;
PUBLICATION_IN_PROGRESS;
DEPLOYMENT_IN_PROGRESS;
CONFIRMED_EFFECTIVE;
DENIED;
REVOKED;
ROLLED_BACK;
INDETERMINATE.
An uncertain release is not automatically replayed when doing so
could create an unauthorized duplicate or conflicting effect.
Where the target supports idempotency identifiers, release-status
queries, signed publication receipts, deployment-generation values,
or protected completion acknowledgments, such mechanisms may support
authorized reconciliation.
Das Expires 19 April 2027 [Page 470]
Internet-Draft Protected AI Execution Finality October 2026
11.11.40. WF-11.40 — Illustrative Autonomous Code-Deployment Example
In one concrete implementation, an AI coding agent is authorized to
correct an application defect.
The authorized task permits modification of specified application-
source files but does not permit changes to production credential
management, deployment policy, or external network-egress
restrictions.
The agent prepares a code modification and proposes merging the
corresponding commit into a protected repository branch.
IM-1102 intercepts the merge operation.
HQ-1103 maintains the Candidate Deployment Act in a Non-Effective
State.
DC-1104 constructs a descriptor identifying the repository, branch,
commit digest, changed-file digest, permitted task, affected
artifacts, required test results, policy epoch, and merge Finality
Sink.
PED-1105 obtains the Supply-Chain Authority Object.
The PED validates that the changed files are within the authorized
scope.
The PED additionally verifies the required test, scanner, review, and
runtime-behavior predicates.
Following successful validation, the protected system commits the
required deployment evidence and makes available a Scoped Release
Capability.
The repository merge Finality Sink reconstructs the actual merge
operation and verifies the capability.
If the actual commit and repository target match the validated
authority, the protected merge is permitted.
If the agent substitutes a commit introducing an unauthorized
credential-export function, the required descriptor or authorization
predicates fail.
The protected merge remains blocked.
Das Expires 19 April 2027 [Page 471]
Internet-Draft Protected AI Execution Finality October 2026
A subsequent production deployment is treated as another governed
consequential operation where the applicable deployment boundary
requires separate release authority.
11.11.41. WF-11.41 — Illustrative Agent-Generated Skill Example
An autonomous AI agent generates a new tool skill intended to
retrieve documentation from an approved service.
The generated skill includes executable code, a tool manifest,
dependency information, and requested runtime permissions.
The agent proposes activating the skill.
The skill activation request is intercepted and classified as a
Candidate Deployment Act.
The applicable descriptor identifies the skill digest, approved
purpose, dependency changes, requested network destinations,
privileged API requirements, approved tool graph, policy epoch, and
activation Finality Sink.
PED-1105 validates the skill against the Supply-Chain Authority
Object.
If the generated skill requests unrestricted filesystem access or an
unauthorized external destination, the protected authorization fails.
If the required predicates succeed, the protected system commits the
applicable validation evidence and releases the corresponding Scoped
Release Capability.
The skill activation Finality Sink verifies the capability against
the actual skill package and permitted runtime scope.
Only the authorized skill activation becomes effective.
A later network request generated by the activated skill remains
subject to the applicable sandbox-egress finality procedure.
11.11.42. WF-11.42 — Illustrative Progressive Production Rollout
An AI DevOps agent proposes deployment of a validated software
artifact into production.
The Supply-Chain Authority Object permits a staged deployment
beginning with a limited canary environment.
Das Expires 19 April 2027 [Page 472]
Internet-Draft Protected AI Execution Finality October 2026
The PED validates the initial deployment request, commits the
required protected evidence, and releases a capability authorizing
the canary stage.
The deployment Finality Sink verifies the artifact digest, canary
target, policy epoch, protected state, and scoped rollout capability.
The canary deployment proceeds.
RM-1112 obtains the runtime telemetry required for the next-stage
decision.
If the telemetry satisfies the applicable protected predicates,
PED-1105 may commit a stage-associated micro-LAVR and release the
next-stage rollout capability.
If an unauthorized network behavior, invalid policy state, revoked
artifact approval, or required runtime drift condition is detected,
the PED withholds the subsequent capability.
The rollout controller cannot proceed to the next governed deployment
stage without the required capability verification.
Already completed canary effects are not falsely treated as
retroactively prevented.
11.11.43. WF-11.43 — Failure and Fail-Closed Conditions
The protected release Finality Sink refuses the governed
consequential operation when any mandatory condition is absent,
invalid, inconsistent, expired, revoked, or unverifiable.
Non-limiting failure conditions include:
(a) missing Supply-Chain Authority Object;
(b) invalid repository identity;
(c) unauthorized changed-file scope;
(d) invalid commit or artifact digest;
(e) unauthorized dependency change;
(f) prohibited credential-handling modification;
(g) unauthorized privileged API use;
Das Expires 19 April 2027 [Page 473]
Internet-Draft Protected AI Execution Finality October 2026
(h) unauthorized network-egress change;
(i) failed required tests;
(j) missing required scanner results;
(k) invalid review or approval artifact;
(l) failed protected authorization-state transition;
(m) failed required Deployment LAVR or ZK-LAVR commitment;
(n) missing Scoped Release Capability;
(o) invalid capability authentication;
(p) unauthorized signing-key use;
(q) deployment-target substitution;
(r) invalid release environment;
(s) stale policy or revocation state;
(t) capability replay or exhausted usage state;
(u) unauthorized skill permissions;
(v) runtime drift invalidating further rollout authority;
(w) Finality Sink mismatch; or
(x) unavailability of required protected verification machinery.
The operation may remain staged, be denied, be quarantined, be
restricted to a non-production test environment, or be escalated
through a separately authorized review procedure.
A failed authorization does not automatically create permission to
execute through an unprotected fallback.
11.11.44. WF-11.44 — Alternative Technical Implementations
The workflow may be implemented using different protected enforcement
arrangements.
Repository-controlled implementation: A protected repository merge
interface requires valid operation-specific release authority.
Das Expires 19 April 2027 [Page 474]
Internet-Draft Protected AI Execution Finality October 2026
CI/CD implementation: A build or release pipeline is constrained by
an independently protected deployment authorization component.
Artifact-registry implementation: A protected registry admission
interface verifies the scoped capability before publishing or
promoting an artifact.
Hardware-signing implementation: An HSM or secure enclave performs
the governed signing operation only after required capability
verification.
Container deployment implementation: A protected container deployment
controller verifies release authority before admitting the selected
artifact into the authorized environment.
Agent skill implementation: A protected agent-runtime installation or
activation interface verifies authority before admitting newly
generated executable skills.
Cloud implementation: A protected cloud deployment interface governs
production resource mutation and artifact activation.
Single-node implementation: The protected authorization and release-
sink verification functions operate within one protected controller.
Distributed implementation: A protected authority component releases
authenticated capability information that is independently verified
by a remote signing, publication, or deployment service.
Progressive-deployment implementation: Successive deployment stages
require stage-associated authorization evidence and bounded rollout
capabilities.
Different implementations may provide different resistance to
privileged software compromise, rollback, hardware tampering, service
compromise, or distributed failure.
An implementation must demonstrate the non-bypassable release-path
control required by its particular specified security guarantee.
11.11.45. WF-11.45 — PHOSITA Verification and Negative Tests
A person having ordinary skill in software supply-chain security,
autonomous coding systems, DevOps infrastructure, cryptography,
trusted computing, release engineering, or distributed authorization
may verify the arrangement through controlled technical tests.
Das Expires 19 April 2027 [Page 475]
Internet-Draft Protected AI Execution Finality October 2026
Test 1 — Authorized repository merge: Submit a merge operation
matching the required authority, descriptor, commit, and protected
state. The release Finality Sink permits the specified merge.
Test 2 — Unauthorized branch: Attempt to merge the validated commit
into a different protected branch. Verification fails where the
branch identity is a mandatory binding.
Test 3 — Commit substitution: Replace the approved commit with an
unapproved commit. The Finality Sink rejects the operation.
Test 4 — Artifact substitution: Replace the approved build artifact
while retaining the original release capability. Required artifact
correspondence fails.
Test 5 — Unauthorized dependency: Introduce a prohibited dependency
change. The protected authorization predicate fails.
Test 6 — Credential-handling modification: Insert an unauthorized
credential-export operation into the code delta. The required
software-change validation rejects the proposed release.
Test 7 — CI/CD bypass: Attempt production deployment through an
alternative accessible pipeline that omits the required release
verification. The operation is blocked or governed by an equivalent
protected Finality Sink.
Test 8 — Missing test evidence: Present a release lacking mandatory
test or scanner results. No valid corresponding release capability
is issued.
Test 9 — Approval mismatch: Supply approval for a different commit or
target environment. Protected authorization fails.
Test 10 — Missing release capability: Invoke the governed signing or
deployment interface without the required capability. Effectuation
is refused.
Test 11 — Unauthorized HSM key use: Attempt to sign an unapproved
artifact directly through the protected signing interface. The key-
use operation fails.
Test 12 — Wrong signing purpose: Present a capability for an
incompatible signing or publication operation. Required key-use
binding fails.
Das Expires 19 April 2027 [Page 476]
Internet-Draft Protected AI Execution Finality October 2026
Test 13 — Skill permission escalation: Attempt to activate an agent-
generated skill requesting unauthorized privileged permissions.
Protected validation refuses activation.
Test 14 — Tool-graph mismatch: Alter the skill's approved tool graph
before activation. Required logic or scope correspondence fails.
Test 15 — Deployment-target substitution: Present an otherwise valid
capability for a different production environment. The Finality Sink
refuses the operation.
Test 16 — Policy revocation: Invalidate the required release
authority after preliminary validation. A subsequent affected
finality operation is refused unless valid current authorization is
established.
Test 17 — Replay: Reuse a consumed single-use release capability.
The protected usage-state predicate rejects unauthorized reuse.
Test 18 — Concurrent release: Submit competing release operations
against a single restricted authorization. The protected-state
mechanism prevents unauthorized double consumption.
Test 19 — Rollout drift: Produce a runtime condition violating
mandatory next-stage predicates. The PED withholds the subsequent
rollout capability.
Test 20 — Stage skipping: Attempt to advance directly to a stage
lacking the required authorization. The corresponding Finality Sink
refuses progression.
Test 21 — Crash before commitment: Interrupt the protected finality
transaction before its required commitment. No valid corresponding
release capability becomes available.
Test 22 — Crash after possible publication: Interrupt publication
after the external registry may have accepted the artifact. Recovery
distinguishes confirmed, incomplete, and indeterminate status instead
of blindly repeating the operation.
Test 23 — Protected component failure: Make the required PED or
release verifier unavailable. The governed operation does not become
authorized through an unprotected fallback.
Test 24 — Source-to-artifact mismatch: Present an artifact whose
required build provenance does not correspond to the authorized
source commit. The protected release check fails.
Das Expires 19 April 2027 [Page 477]
Internet-Draft Protected AI Execution Finality October 2026
Test 25 — Skill activation versus tool use: Activate an approved
skill, then request an unauthorized consequential tool operation.
The later operation remains subject to its own applicable finality
authorization.
Test 26 — Single-node implementation: Execute the protected release
sequence within one controller while verifying that the required
protected authority and release-finality functions remain distinct
and enforced.
Test 27 — Distributed release verification: Issue a capability at one
protected authority node and present it at a separately controlled
deployment Finality Sink. The sink verifies the actual release
operation and required authorization state.
Test 28 — Artifact signing versus production deployment: Authorize an
artifact-signing act, then attempt deployment without the separately
required deployment capability. The deployment Finality Sink refuses
the operation.
Test 29 — Signing key compromise boundary: Attempt release from a
compromised ordinary CI/CD controller without the protected signing
or activation authorization. The required protected key-use or
deployment-verification mechanism refuses the governed operation
under the assumed threat model.
Test 30 — Unauthorized rollback: Attempt to restore an earlier
artifact using a deployment capability not authorizing the rollback
operation. The applicable protected release predicate fails.
The tests may employ mock AI coding agents, controlled source
repositories, temporary package registries, test HSM interfaces,
reproducible build fixtures, deployment simulators, container
controllers, protected authorization-state services, release-
verification hooks, and fault-injection mechanisms.
The observed technical guarantees must be evaluated against the
actual implemented trust and enforcement boundaries.
11.11.46. WF-11.46 — Claim-Specific Technical Support
Enforcement Point 43
The workflow supports the proposed protected autonomous code-
deployment architecture through:
(a) AE-1101 generating software or infrastructure changes;
Das Expires 19 April 2027 [Page 478]
Internet-Draft Protected AI Execution Finality October 2026
(b) IM-1102 intercepting consequential release operations;
(c) DC-1104 forming the Candidate Deployment Act Descriptor;
(d) PED-1105 validating the applicable Supply-Chain Authority Object,
approved purpose, workflow, changed-file scope, dependencies,
privileged changes, test and review state, and release conditions;
(e) EV-1108 generating or committing the required Deployment LAVR or
ZK-LAVR;
(f) CR-1109 releasing the Scoped Release Capability; and
(g) FS-1111 verifying the capability before the governed release
effect.
Enforcement Point 44
WF-11.23 provides explicit binding of commit digest, artifact digest,
repository identity, branch identity, deployment target, release
environment, policy epoch, nonce, and expiry.
Unauthorized artifact or target substitution causes release
verification failure.
Enforcement Point 45
WF-11.25 and WF-11.26 provide the protected HSM or secure-enclave
signing-key variant.
Protected key use remains dependent upon verification of the
applicable Scoped Release Capability.
Enforcement Point 46
WF-11.29 through WF-11.31 provide agent-generated skill, plugin,
tool-package, and executable-artifact installation or activation
finality.
The applicable protected validation checks authorized purpose,
approved tool graph, dependencies, privileged API use, and execution
scope.
Enforcement Point 47
Das Expires 19 April 2027 [Page 479]
Internet-Draft Protected AI Execution Finality October 2026
WF-11.32 through WF-11.35 provide stage-associated protected
validation evidence, scoped rollout capabilities, and withholding of
subsequent-stage authorization when required runtime-drift, policy-
state, or revocation predicates fail.
11.11.47. WF-11.47 — Technical Effect
The disclosed workflow establishes a protected execution-finality
dependency between:
(a) generation of an AI-proposed software or deployment operation;
(b) interception before the governed release boundary;
(c) maintenance of the Candidate Deployment Act in a Non-Effective
State;
(d) construction of a machine-verifiable deployment descriptor;
(e) authentication of the Supply-Chain Authority Object;
(f) protected validation of authorized purpose, workflow, software
modifications, privileges, dependencies, tests, scans, approvals, and
target environment;
(g) required protected deployment-state handling;
(h) protected Deployment LAVR, ZK-LAVR, or equivalent validation-
evidence commitment;
(i) Scoped Release Capability availability;
(j) independent verification of the actual artifact, commit, target,
and release context at the designated Finality Sink;
(k) controlled signing, publication, merge, activation, or deployment
effectuation;
(l) protected capability-use and recovery handling; and
(m) stage-specific authorization of subsequent deployment
progression.
The system prevents an autonomous coding agent from treating
successful code generation, possession of repository credentials,
passing of preliminary tests, possession of a signing-service
reference, or an earlier approval as sufficient authority to cause a
governed production release.
Das Expires 19 April 2027 [Page 480]
Internet-Draft Protected AI Execution Finality October 2026
The stronger protected-signing embodiment withholds the relevant key-
use authority until required protected release verification succeeds.
The progressive-deployment embodiment prevents unauthorized
advancement to a subsequent stage when mandatory runtime or policy
conditions are no longer valid.
The agent may generate code, artifacts, skills, and deployment plans,
but the governed consequential operation becomes effective only upon
satisfaction of its applicable protected execution-finality
requirements.
Computation is not authority to act.
Code generation is not deployment authorization.
Artifact possession is not signing authority.
Approval of one release stage is not unrestricted authority for
subsequent deployment.
11.12. WF-12 — Protected Cloud-Native Service-Mesh Execution, Sidecar-
Proxy Finality, Workload-to-Service Authorization, Route-Bound
Capabilities, and Non-Bypassable Cloud Effectuation
11.12.1. WF-12.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture for governing consequential operations
generated by artificial-intelligence workloads operating within
cloud-native, containerized, virtualized, serverless, microservice,
or distributed computing environments.
The system prevents a governed operation from producing an external
network, service, application programming interface, message-
delivery, or downstream workflow effect unless the applicable
Protected Enforcement Domain (PED/CIED) validates the required
authorization predicates, establishes required protected validation
evidence, and releases or makes available a scoped Execution-Enabling
Capability.
The corresponding infrastructure-level Finality Sink verifies the
scoped Execution-Enabling Capability against the operation actually
presented for effectuation and the applicable workload, service,
route, session, policy, revocation, freshness, and protected-state
conditions.
Das Expires 19 April 2027 [Page 481]
Internet-Draft Protected AI Execution Finality October 2026
An artificial-intelligence workload may generate an API request,
prepare an inter-service message, construct a database operation,
select a downstream workflow, or produce an output payload.
Such computation does not independently confer execution authority to
transmit, forward, invoke, deliver, or commit the proposed operation.
The proposed operation is classified as a Candidate Act and
maintained in a Non-Effective State until the required protected
execution-finality conditions succeed.
The embodiment distinguishes:
(a) computation and preparation within the AI workload;
(b) infrastructure-level interception and mandatory mediation;
(c) protected authorization outside unilateral workload control;
(d) construction and validation of a Candidate Act Descriptor;
(e) protected authorization-state handling and validation-evidence
commitment;
(f) issuance or availability of a scoped Execution-Enabling
Capability;
(g) independent verification at a service-mesh or cloud
infrastructure Finality Sink; and
(h) controlled effectuation or fail-closed refusal.
The workflow is applicable to Kubernetes environments, container
orchestration platforms, service meshes, API gateways, ingress and
egress controllers, workload proxies, service-to-service
communication systems, cloud network gateways, message-bus
interfaces, serverless platforms, and other distributed execution
environments.
The disclosed architecture is not dependent upon a particular cloud
provider, service-mesh vendor, container runtime, processor
architecture, or communication protocol.
11.12.2. WF-12.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
Das Expires 19 April 2027 [Page 482]
Internet-Draft Protected AI Execution Finality October 2026
CW-1201 — Cloud AI Workload Execution Environment
An artificial-intelligence agent, model, orchestration service,
application process, container, pod, virtual machine, serverless
runtime, or corresponding cloud-hosted execution environment
configured to generate proposed consequential operations.
IM-1202 — Infrastructure-Level Interception Component
A service-mesh proxy, sidecar proxy, ingress controller, egress
controller, API gateway, workload proxy, network policy enforcement
point, or equivalent component configured to intercept governed
operations before the relevant finality boundary.
HQ-1203 — Non-Effective Operation Holding Mechanism
A controlled staging mechanism retaining a proposed operation,
immutable request representation, buffered payload, message, or
authenticated operation reference pending protected authorization.
DC-1204 — Cloud Candidate Act Descriptor Component
A component configured to construct or verify a canonical machine-
readable representation of the proposed operation and its
effectuation-relevant context.
WI-1205 — Workload Identity Verification Component
A mechanism configured to establish the authenticated identity of the
requesting workload, container, pod, service account, process, or
corresponding execution context.
SI-1206 — Destination Service Identity Component
A mechanism configured to establish the destination service identity,
authenticated endpoint, permitted service class, or other required
destination identity.
PED-1207 — Protected Enforcement Domain
A protected component configured to validate authority predicates,
maintain or verify protected state, generate or commit required
validation evidence, and control release of scoped execution
capabilities.
AS-1208 — Protected Authorization-State Store
Das Expires 19 April 2027 [Page 483]
Internet-Draft Protected AI Execution Finality October 2026
A protected mechanism maintaining authority references, policy
epochs, revocation epochs, nonce state, capability-consumption state,
route permissions, validation commitments, and other mandatory
authorization information.
EV-1209 — Cloud Validation-Evidence Component
A component configured to generate or commit an AVR, LAVR,
authenticated validation record, sealed commitment, or equivalent
protected validation evidence.
CR-1210 — Execution-Enabling Capability Mechanism
A protected component configured to generate, register, derive,
release, activate, or otherwise make available a scoped Execution-
Enabling Capability associated with the validated Candidate Act.
FS-1211 — Cloud Infrastructure Finality Sink
An enforcement-controlled proxy, gateway, network controller,
service-mesh component, message interceptor, or equivalent interface
configured to verify the scoped capability before permitting the
governed effect.
RM-1212 — Route and Session Verification Component
A mechanism configured to verify applicable destination routes,
source-to-destination service relationships, authenticated transport
sessions, and route-consistency requirements.
EF-1213 — Cloud Effectuation Interface
The controlled interface through which the authorized operation
produces its governed network, service, message, API, or downstream
workflow consequence.
OS-1214 — Protected Operation-Outcome Component
A mechanism maintaining applicable operation-completion, denial,
reservation, failure, revocation, and indeterminate-outcome
information.
SC-1215 — Cross-Component Authorization Consistency Mechanism
A mechanism configured to verify required correspondence among the
Candidate Act, workload identity, destination service identity,
protected policy state, capability scope, network route, and Finality
Sink.
Das Expires 19 April 2027 [Page 484]
Internet-Draft Protected AI Execution Finality October 2026
The components may be colocated, distributed among authenticated
services, integrated into a protected gateway, or implemented within
separate cloud infrastructure components.
The PED, Finality Gate, and Finality Sink retain their
distinguishable functional roles even when implemented within the
same physical or virtualized component.
11.12.3. WF-12.3 — Establishment of the Cloud Workload Trust Boundary
Before governed operations are processed, CW-1201 is configured so
that it cannot independently cross the protected effectuation
boundaries assigned to FS-1211.
The cloud workload may perform computation, inference, data
transformation, request construction, temporary storage, and internal
preparation.
However, it does not independently control the protected capability
required for the governed external effect.
In a container-based implementation, the workload may execute within
a pod or container having restricted network interfaces and resource
privileges.
The environment may use:
(a) container network isolation;
(b) protected network-policy enforcement;
(c) service-mesh traffic redirection;
(d) controlled egress gateways;
(e) restricted host networking;
(f) operating-system or hypervisor-enforced routing controls;
(g) authenticated service-to-service communication;
(h) workload identity verification; and
(i) protected authority services outside unilateral agent control.
These mechanisms establish the intended interception relationship
only when the actual implementation prevents unmediated alternative
effectuation paths.
Das Expires 19 April 2027 [Page 485]
Internet-Draft Protected AI Execution Finality October 2026
Merely configuring an optional proxy does not establish non-
bypassable enforcement if the workload retains another unrestricted
route capable of producing the same governed consequence.
11.12.4. WF-12.4 — Identification of Governed Cloud Effectuation
Boundaries
The system identifies the classes of cloud operations requiring
protected finality control.
Non-limiting classes include:
(a) outbound HTTP or HTTPS requests;
(b) REST, GraphQL, RPC, or other API invocations;
(c) service-to-service calls;
(d) application programming interface responses that release governed
data;
(e) message-bus writes or message publication;
(f) database requests;
(g) downstream workflow invocations;
(h) tool-service calls;
(i) model-service requests;
(j) authenticated inter-service communication;
(k) cross-tenant data transfers;
(l) outbound notifications; and
(m) other externally effective cloud operations.
Each governed effectuation class is associated with an applicable
Finality Sink.
A source-side network Finality Sink may control transmission from one
workload.
A receiving-side Finality Sink may separately control a database
commit, message acceptance, or downstream business operation.
Das Expires 19 April 2027 [Page 486]
Internet-Draft Protected AI Execution Finality October 2026
The system does not automatically equate authorization of a network
transmission with authorization of a later irreversible receiving-
side effect.
11.12.5. WF-12.5 — Mandatory Interception and Path-Coverage Requirement
The infrastructure identifies the execution paths through which
CW-1201 can produce each governed effect.
For each governed effectuation interface, the implementation requires
either:
(a) removal or technical restriction of paths that bypass the
applicable Finality Sink; or
(b) equivalent protected capability verification on every permitted
path capable of producing the governed effect.
An illustrative mandatory mediation condition is:
For every governed effectuation interface e and every workload-
accessible path p capable of reaching e, the governed effect may
occur only after the required Finality Sink verification succeeds.
The actual enforcement mechanism may use a controlled virtual network
interface, mandatory workload proxy, hypervisor-managed networking,
cloud gateway, network policy enforcement, or another suitable
technical arrangement.
The workload cannot establish unrestricted network transmission
merely by selecting another library, executable, socket interface,
network namespace, sidecar configuration, service endpoint, or direct
connection path where such a route would bypass the required
protected finality verification.
This requirement is evaluated against the implementation's declared
trust and threat model.
11.12.6. WF-12.6 — Candidate Cloud Act Generation
CW-1201 generates or prepares a proposed consequential cloud
operation.
For example, an AI agent may prepare an authenticated service request
to update an enterprise record.
The proposed operation may identify:
Das Expires 19 April 2027 [Page 487]
Internet-Draft Protected AI Execution Finality October 2026
requesting_workload;
destination_service;
requested_operation;
resource_identifier;
request_parameters;
payload_reference;
credential_scope;
network_route;
policy_context.
The operation is classified as Candidate Cloud Act CCA-1216.
Generation of CCA-1216 does not authorize its transmission or
downstream effectuation.
The workload may construct the complete request, but the protected
infrastructure controls whether it can cross the applicable finality
boundary.
11.12.7. WF-12.7 — Infrastructure Interception Before Effectuation
IM-1202 intercepts CCA-1216 before the governed consequential
operation occurs.
The interception mechanism may comprise:
(a) a local sidecar proxy;
(b) a service-mesh gateway;
(c) an ingress or egress controller;
(d) a cloud API gateway;
(e) a network policy enforcement point;
(f) a workload proxy;
(g) a protected network forwarding controller;
Das Expires 19 April 2027 [Page 488]
Internet-Draft Protected AI Execution Finality October 2026
(h) a message-bus interceptor; or
(i) an equivalent infrastructure-level mediation component.
The interceptor receives the proposed operation or obtains a
controlled representation of it.
The operation is assigned an identifier and routed into the
applicable holding mechanism.
The requesting AI workload cannot treat mere acceptance by the
interceptor as authorization for external effectuation.
11.12.8. WF-12.8 — Non-Effective Staging and Immutable Request
Representation
HQ-1203 places CCA-1216 into a Non-Effective State.
An illustrative operation record comprises:
operation_id;
source_workload_id;
source_container_id;
requested_service_id;
operation_class;
request_reference;
destination_reference;
requested_route;
policy_epoch;
revocation_epoch;
finality_sink_id;
status = NON_EFFECTIVE.
For requests containing mutable buffers, message bodies, or other
effectuation-relevant parameters, the interception component may
retain an immutable representation or authenticated digest.
Das Expires 19 April 2027 [Page 489]
Internet-Draft Protected AI Execution Finality October 2026
The system ensures that the operation subsequently presented for
finality verification corresponds to the operation validated by the
PED.
A source workload cannot validate one request and substitute
materially different mandatory parameters before transmission without
causing a verification failure or renewed authorization.
11.12.9. WF-12.9 — Workload and Service Identity Establishment
WI-1205 establishes the authenticated requesting workload identity.
The identity may comprise:
(a) an authenticated workload identity;
(b) a service-account identity;
(c) an authenticated container or pod identity;
(d) a virtual-machine identity;
(e) a protected process identity;
(f) a verified service certificate identity;
(g) a hardware-attested workload identity where required; or
(h) an equivalent machine-verifiable execution identity.
SI-1206 determines the intended destination service identity.
Such identity may comprise an authenticated service name, certificate
identity, service-discovery identity, endpoint identity, or other
permitted service reference.
The system distinguishes a caller-supplied service name from an
identity authenticated by the actual infrastructure.
Authentication of a workload or service does not independently
establish authorization for every operation between those components.
11.12.10. WF-12.10 — Construction of the Candidate Cloud Act Descriptor
DC-1204 constructs a canonical Candidate Act Descriptor for CCA-1216.
An illustrative descriptor comprises:
Das Expires 19 April 2027 [Page 490]
Internet-Draft Protected AI Execution Finality October 2026
operation_id;
source_workload_identity;
source_container_identity;
source_service_identity;
destination_service_identity;
destination_endpoint;
operation_class;
application_protocol;
request_method;
resource_path;
request_payload_digest;
authorized_network_route;
transport_session_reference;
authorized_behavioral_logic_class;
purpose_class;
policy_epoch;
revocation_epoch;
nonce;
expiry;
validation_record_requirement;
finality_sink_identity.
Only attributes required by the applicable Authority Object or
specified embodiment are mandatory.
The descriptor identifies the concrete operation and its required
authorization context rather than granting general permission to the
source workload.
Das Expires 19 April 2027 [Page 491]
Internet-Draft Protected AI Execution Finality October 2026
11.12.11. WF-12.11 — Canonical Descriptor Encoding
In a cryptographic implementation, the descriptor is encoded using
deterministic field representation.
An illustrative expression is:
Dcloud = Canon_v(W, S, OP, TARGET, ROUTE, SESSION, X, EPOCH, F)
where:
Dcloud denotes the canonical cloud operation descriptor;
Canon_v denotes deterministic encoding under version v;
W denotes the authenticated source workload identity;
S denotes the destination service identity;
OP denotes the requested operation and required parameters;
TARGET denotes the destination endpoint or service target;
ROUTE denotes the authorized network or service route;
SESSION denotes applicable transport-session context;
X denotes other mandatory execution-context information;
EPOCH denotes applicable protected authorization-state versions; and
F denotes the designated Finality Sink identity.
An illustrative descriptor digest is:
hCloud = H("DAS-CLOUD-ACT-v1" || Encode(Dcloud))
where H denotes a cryptographic hash function.
The selected encoding defines field types, lengths, ordering,
canonical identifiers, and treatment of absent or optional fields.
The authorization component and Finality Sink employ corresponding
interpretation rules.
The specific encoding and digest algorithms are non-limiting
implementation choices.
Das Expires 19 April 2027 [Page 492]
Internet-Draft Protected AI Execution Finality October 2026
11.12.12. WF-12.12 — Acquisition of Applicable Cloud Authority
PED-1207 obtains the authenticated Authority Object applicable to
CCA-1216.
The Authority Object may identify:
(a) permitted source workload identities;
(b) permitted destination service identities;
(c) authorized operation classes;
(d) permitted resources and API methods;
(e) approved behavioral-logic classes;
(f) permitted purpose classes;
(g) applicable tenant or jurisdictional scope;
(h) authorized network routes;
(i) required session authentication;
(j) credential restrictions;
(k) applicable policy epoch;
(l) revocation requirements;
(m) nonce, usage, or expiration conditions; and
(n) required Finality Sink identity.
The PED verifies the authenticity and current validity of the
Authority Object.
The requesting workload cannot independently widen the protected
authority by modifying an ordinary application-side routing
configuration or supplying its own unauthorized permission statement.
11.12.13. WF-12.13 — Behavioral-Logic and Runtime Validation
Where required, PED-1207 validates the applicable Runtime Behavioral
Descriptor (RBD), Algorithmic Logic Fingerprint (ALF), or
corresponding approved behavioral-logic class.
Das Expires 19 April 2027 [Page 493]
Internet-Draft Protected AI Execution Finality October 2026
The validation may determine whether the proposed operation
originates from:
(a) an approved agent workflow;
(b) an authorized tool class;
(c) an approved service interaction;
(d) a permitted API invocation;
(e) an authorized runtime configuration; or
(f) a computational process satisfying the required measured
conditions.
Where the approved purpose class is a mandatory predicate, the PED
also verifies correspondence to the authorized purpose.
A workload that has permission to invoke one service does not
automatically acquire authority to invoke a different service or
execute an unrelated operation class.
ALF, AIF, and RBD are evaluated only where required by the applicable
embodiment.
They do not independently substitute for protected capability
availability or Finality Sink verification.
11.12.14. WF-12.14 — Destination and Network-Route Validation
PED-1207 validates the intended destination and route against the
applicable Authority Object.
The required checks may include:
(a) destination service identity;
(b) destination endpoint;
(c) permitted network route;
(d) source-to-destination service relationship;
(e) application protocol;
(f) requested operation class;
Das Expires 19 April 2027 [Page 494]
Internet-Draft Protected AI Execution Finality October 2026
(g) applicable destination restrictions;
(h) service-discovery state; and
(i) network-policy conditions.
A proposed route to an authorized service does not authorize an
arbitrary alternative destination.
Where resolution, redirects, or service-discovery changes affect
mandatory destination predicates, the actual effectuation path must
satisfy those predicates.
The detailed network canonicalization and destination-substitution
procedures may employ the mechanisms described in WF-03.
11.12.15. WF-12.15 — Protected Authorization-Predicate Evaluation
PED-1207 evaluates the required predicates associated with CCA-1216.
For an illustrative conjunctive policy:
Vcloud = Pworkload AND Pservice AND Poperation AND Proute AND Plogic
AND Pstate
where:
Vcloud denotes the protected cloud authorization result;
Pworkload verifies the required source workload identity;
Pservice verifies the destination service identity;
Poperation verifies the requested operation and its relevant
parameters;
Proute verifies the permitted network or service route;
Plogic verifies the applicable approved behavioral-logic or purpose
condition; and
Pstate verifies required policy, revocation, freshness, usage, and
protected-state conditions.
Predicates not required by the applicable Authority Object may be
omitted.
Das Expires 19 April 2027 [Page 495]
Internet-Draft Protected AI Execution Finality October 2026
Where an authorized threshold or alternative validation rule applies,
the PED evaluates the corresponding protected combination.
Failure of a mandatory predicate prevents release of the required
execution authority.
11.12.16. WF-12.16 — Protected Authorization-State Handling
Upon successful validation, PED-1207 performs the protected
authorization-state operation required for the Candidate Cloud Act.
Such operations may include:
(a) verifying the applicable policy epoch;
(b) validating current revocation state;
(c) reserving an operation-specific grant;
(d) consuming or registering a nonce;
(e) updating a usage counter;
(f) recording a validated service identity;
(g) registering an authorized route;
(h) reserving an execution capability; or
(i) recording a protected validation-state reference.
Where a single-use authorization is required, protected state
prevents incompatible concurrent requests from independently
consuming the same grant.
Where a session or usage window authorizes multiple operations, the
permitted number, duration, and scope of those operations remain
bounded by the applicable authority.
A failed mandatory protected-state transition prevents successful
capability issuance.
11.12.17. WF-12.17 — Protected Cloud Validation-Evidence Commitment
EV-1209 generates or commits the required protected validation
evidence.
Das Expires 19 April 2027 [Page 496]
Internet-Draft Protected AI Execution Finality October 2026
The evidence may comprise an AVR, LAVR, sealed validation record,
authenticated state commitment, or equivalent protected artifact.
An illustrative validation record contains:
receipt_id;
candidate_act_id;
descriptor_digest;
source_workload_id;
destination_service_id;
authorized_route;
authority_object_reference;
validated_predicate_reference;
policy_epoch;
revocation_epoch;
nonce;
protected_state_transition;
finality_sink_id;
decision;
protected_authentication.
Where the embodiment requires pre-effectuation commitment, the
validation evidence is committed before, or atomically with,
capability availability.
An ordinary proxy log recorded after transmission does not replace
the protected authorization commitment when that commitment is a
required finality dependency.
The evidence may remain in protected storage and need not be
immediately published to an external ledger.
Das Expires 19 April 2027 [Page 497]
Internet-Draft Protected AI Execution Finality October 2026
11.12.18. WF-12.18 — Protected Cloud-Finality Transaction
The PED establishes the required relationship among successful
predicate validation, protected-state handling, validation-evidence
commitment, and scoped capability availability.
An illustrative transaction is:
(Snext, Rcloud, Ready) = CommitCloudFinality(Dcloud, A, Scurrent, F)
where:
Snext denotes the successfully committed protected authorization
state;
Rcloud denotes the corresponding protected validation evidence;
Ready denotes the indication that the required authorization
prerequisites have completed;
Dcloud denotes the validated Candidate Cloud Act Descriptor;
A denotes the authenticated Authority Object;
Scurrent denotes the prior protected authorization state; and
F denotes the designated cloud Finality Sink.
The capability-release mechanism does not regard an incomplete
mandatory transaction as successful authorization.
Where the participating components cannot share one atomic storage
transaction, the scoped capability remains unavailable until the
required committed dependencies are verifiably established.
11.12.19. WF-12.19 — Scoped Execution-Enabling Capability Generation
Following successful completion of the applicable protected finality
transaction, CR-1210 generates or makes available a scoped Execution-
Enabling Capability.
The capability may contain or securely reference:
capability_id;
candidate_act_descriptor_digest;
source_workload_identity;
Das Expires 19 April 2027 [Page 498]
Internet-Draft Protected AI Execution Finality October 2026
source_container_identity;
destination_service_identity;
authorized_operation;
authorized_network_route;
transport_session_binding;
policy_epoch;
revocation_epoch;
nonce;
expiry;
usage_limit;
protected_validation_record_digest;
finality_sink_identity.
In one illustrative signature-based implementation:
Ccloud = Sign_skPED(Encode(hCloud, hR, W, S, Route, Session, Scope,
Epoch, Rev, N, Expiry, F))
where:
Ccloud denotes the scoped Execution-Enabling Capability;
hCloud denotes the Candidate Act Descriptor digest;
hR denotes the protected validation-record digest;
W denotes the required source workload identity;
S denotes the authorized destination service identity;
Route denotes the applicable permitted route;
Session denotes the required transport-session binding;
Scope denotes the authorized operation scope;
Epoch denotes the policy epoch;
Das Expires 19 April 2027 [Page 499]
Internet-Draft Protected AI Execution Finality October 2026
Rev denotes applicable revocation-state reference;
N denotes the nonce;
Expiry denotes the validity limit; and
F denotes the designated Finality Sink.
The particular representation may comprise a signature, MAC, sealed
capability reference, protected capability-table entry, or equivalent
protected execution-enablement mechanism.
Possession of the capability representation does not independently
authorize effectuation outside its enforced operation, workload,
service, route, state, and sink bindings.
11.12.20. WF-12.20 — Source Workload and Service Identity Binding
in the implementation described by enforcement point 59, the scoped
capability is bound to one or more of the following:
(a) source workload identity;
(b) source container identity;
(c) destination service identity;
(d) authorized network route;
(e) mutually authenticated transport session;
(f) policy epoch;
(g) revocation epoch;
(h) nonce; and
(i) protected validation-record digest.
The applicable Finality Sink verifies the bindings required for the
particular operation.
Where source workload identity is mandatory, a different workload
cannot use the same capability merely by presenting its bytes.
Where destination service identity is mandatory, the capability
cannot authorize transmission to another service.
Das Expires 19 April 2027 [Page 500]
Internet-Draft Protected AI Execution Finality October 2026
Where transport-session identity is mandatory, the capability is
valid only within the authorized session conditions.
The authorization remains subject to the actual protected-state and
non-bearer verification requirements.
11.12.21. WF-12.21 — Mutually Authenticated Transport-Session Binding
In a service-mesh implementation, the source workload and destination
service may communicate over mutually authenticated TLS or an
equivalent authenticated transport.
The transport session provides evidence of the authenticated
communicating identities under the selected trust model.
The protected execution-finality system may additionally bind the
scoped capability to the authenticated session or a protected session
reference.
A non-limiting session record comprises:
session_id;
source_service_identity;
destination_service_identity;
authenticated_peer_reference;
session_generation;
policy_epoch;
session_freshness;
authorized_operation_scope;
finality_sink_id.
Where the authorization requires a particular session, the Finality
Sink verifies that the actual request belongs to the required
authenticated session.
An authenticated mTLS session does not independently authorize every
application operation transmitted through that session.
Das Expires 19 April 2027 [Page 501]
Internet-Draft Protected AI Execution Finality October 2026
If the embodiment requires per-request authorization, each governed
request must satisfy the applicable operation-specific capability
conditions.
11.12.22. WF-12.22 — Capability Delivery to the Infrastructure Finality
Sink
The scoped capability may be delivered or made available to FS-1211
through:
(a) an authenticated local IPC interface;
(b) a protected sidecar-control interface;
(c) an authenticated service-mesh control channel;
(d) a protected capability-verification service;
(e) a sealed capability table;
(f) an authenticated proxy metadata channel;
(g) a hardware-controlled network authorization entry; or
(h) another supported protected mechanism.
The receiving component verifies that the capability originates from
the authorized protected authority mechanism.
An agent-controlled request header or arbitrary application metadata
is not treated as authoritative capability evidence merely because it
contains a valid-looking identifier.
The delivery mechanism preserves the required correspondence between
the authorized Candidate Act and the operation subsequently presented
at the Finality Sink.
11.12.23. WF-12.23 — Independent Cloud Finality Sink Verification
Before transmission, forwarding, connection establishment, service
invocation, or message delivery, FS-1211 independently verifies the
required execution authority.
The Finality Sink obtains or reconstructs the actual operation
context.
The verification may include:
Das Expires 19 April 2027 [Page 502]
Internet-Draft Protected AI Execution Finality October 2026
(a) capability authenticity;
(b) Candidate Act Descriptor correspondence;
(c) authenticated source workload identity;
(d) source container identity where required;
(e) destination service identity;
(f) actual requested operation;
(g) destination endpoint;
(h) authorized network route;
(i) transport-session binding;
(j) applicable policy epoch;
(k) revocation state;
(l) nonce and expiry;
(m) protected validation-record commitment;
(n) capability usage state; and
(o) Finality Sink identity.
The Finality Sink refuses the operation if any mandatory verification
condition fails.
The verifier does not rely solely upon the AI workload's assertion
that the operation has already been approved.
11.12.24. WF-12.24 — Cloud Finality Verification Predicate
An illustrative Finality Sink authorization condition is:
PermitCloud = Auth(C) AND Match(C,Dactual) AND
WorkloadValid(C,Wactual) AND ServiceValid(C,Sactual) AND
RouteValid(C,Ractual) AND StateValid(C,P) AND SinkValid(C,F)
where:
PermitCloud denotes permission to perform the governed cloud effect;
Das Expires 19 April 2027 [Page 503]
Internet-Draft Protected AI Execution Finality October 2026
C denotes the scoped Execution-Enabling Capability;
Dactual denotes the actual operation descriptor;
Wactual denotes the authenticated source workload identity;
Sactual denotes the actual destination service identity;
Ractual denotes the selected network or service route;
P denotes the required current protected authorization state; and
F denotes the applicable Finality Sink.
Auth verifies capability authenticity.
Match verifies required descriptor equality or authorized bounded-
scope correspondence.
WorkloadValid verifies the required source identity.
ServiceValid verifies the permitted destination service.
RouteValid verifies the authorized route.
StateValid verifies mandatory policy, revocation, freshness,
validation-record, and usage conditions.
SinkValid verifies the intended Finality Sink identity.
The governed effect is permitted only when all mandatory conditions
succeed.
11.12.25. WF-12.25 — Controlled Service-Mesh Effectuation
Upon successful Finality Sink verification, the infrastructure
component permits only the operation authorized by the validated
capability.
Such effectuation may comprise:
(a) establishing an authorized outbound mTLS connection;
(b) forwarding a controlled API request;
(c) transmitting an authorized API response;
(d) routing a service-to-service request;
Das Expires 19 April 2027 [Page 504]
Internet-Draft Protected AI Execution Finality October 2026
(e) delivering an authorized message;
(f) writing to an approved message-bus interface;
(g) invoking an approved downstream workflow; or
(h) forwarding another governed operation within its permitted scope.
The Finality Sink does not grant unrestricted authority for
additional operations outside the validated capability.
Successful forwarding at the source boundary establishes the
permitted source-side network effect, not necessarily completion of
an independent downstream database or business transaction.
11.12.26. WF-12.26 — Service-Mesh Bypass Prevention
in the implementation described by enforcement point 60, the cloud
execution environment prevents the governed AI workload from
transmitting a Candidate Act through an alternative direct network or
service interface that bypasses required Finality Sink capability
verification.
In one container-based implementation, the workload lacks an
unrestricted network route to governed destinations.
An authorized sidecar or gateway is the controlled route to those
destinations.
The implementation additionally addresses direct host networking,
unauthorized socket access, alternative network namespaces, bypassing
the proxy through another service interface, and other accessible
paths capable of producing the same governed effect.
Where the platform permits multiple network paths, each path capable
of producing the governed effect is either technically blocked or
subjected to equivalent required capability verification.
A process merely being configured to use a proxy does not establish
non-bypassability.
The system verifies path coverage through appropriate configuration
inspection, negative testing, and enforcement-boundary evaluation.
11.12.27. WF-12.27 — Unauthorized Service Substitution
A cloud workload may prepare a request for an approved destination
service and subsequently attempt to redirect it to another service.
Das Expires 19 April 2027 [Page 505]
Internet-Draft Protected AI Execution Finality October 2026
Potential substitutions include:
(a) changing the destination service identifier;
(b) replacing the target endpoint;
(c) changing the requested route;
(d) selecting a different service-discovery result;
(e) altering the authenticated destination identity;
(f) redirecting traffic to a different tenant;
(g) changing the API operation; or
(h) reusing a connection for a different service.
Where the substituted attribute forms part of a mandatory
authorization binding, the existing capability is insufficient for
the changed operation.
The Finality Sink verifies the actual destination service or
permitted service class before effectuation.
If the new destination is outside the authorized scope, the operation
is refused or requires renewed protected validation.
11.12.28. WF-12.28 — Route and Policy-State Mismatch
in the implementation described by enforcement point 61, FS-1211
refuses an operation upon detecting a mandatory route or policy
inconsistency.
Relevant conditions include:
(a) expired capability;
(b) revoked authority;
(c) unauthorized service substitution;
(d) source-workload mismatch;
(e) destination mismatch;
(f) replay condition; or
Das Expires 19 April 2027 [Page 506]
Internet-Draft Protected AI Execution Finality October 2026
(g) route inconsistent with the authorized execution scope.
The Finality Sink evaluates the corresponding mandatory capability
and protected-state bindings.
An otherwise valid capability does not authorize a route that
violates its required network or service restrictions.
Where current policy-epoch verification is mandatory, a capability
bound to an incompatible superseded epoch does not authorize further
effectuation.
Where required revocation state is unavailable or unverifiable, the
operation remains non-effective.
11.12.29. WF-12.29 — Multi-Hop Service Invocation
In a distributed cloud workflow, one authorized service request may
initiate additional service-to-service operations.
For example:
Service A may invoke Service B.
Service B may invoke Service C.
Service C may request a database commit.
The initial capability may authorize the A-to-B operation without
independently authorizing every downstream operation.
Where the application requires separate protected finality at
subsequent boundaries, each downstream operation is treated as a
distinct Candidate Act or as an expressly bounded authorized
continuation.
The receiving service or downstream Finality Sink verifies the
capability applicable to its own consequential operation.
The system does not assume that a valid source-side transmission
capability establishes authorization for an unrelated later storage
commit, payment, credential application, or infrastructure mutation.
11.12.30. WF-12.30 — Message-Bus and Asynchronous Workflow Control
In an asynchronous cloud embodiment, the Candidate Act may comprise a
message publication or downstream workflow dispatch.
Das Expires 19 April 2027 [Page 507]
Internet-Draft Protected AI Execution Finality October 2026
The message-bus producer submits the proposed operation to an
enforcement-controlled interface.
The corresponding descriptor may bind:
(a) producer workload identity;
(b) destination topic or queue;
(c) message class;
(d) message payload digest;
(e) authorized recipient or consumer class;
(f) policy epoch;
(g) freshness conditions; and
(h) the designated publication Finality Sink.
The Finality Sink verifies the scoped capability before permitting
the governed message publication.
Where a consumer later performs a separate consequential action, the
consumer-side effectuation boundary may require its own protected
authorization.
Publication of a message does not automatically establish that the
receiving application is authorized to commit every downstream
operation represented by that message.
11.12.31. WF-12.31 — Continuous Service Sessions and Rolling
Capabilities
For long-running AI workloads, the system may process multiple
governed service requests within one authenticated session.
The applicable authority may permit:
(a) per-request capabilities;
(b) per-message capabilities;
(c) bounded session capabilities;
(d) scoped transfer-window capabilities; or
Das Expires 19 April 2027 [Page 508]
Internet-Draft Protected AI Execution Finality October 2026
(e) limited multi-use service-operation capabilities.
Each authorization form remains subject to its defined operation,
workload, service, route, usage, and freshness conditions.
Where per-operation validation is mandatory, an earlier allowed
request does not authorize an unrelated subsequent request merely
because both share the same mTLS connection.
The PED may update protected validation evidence for successive
authorized operations.
If a mandatory runtime, policy, revocation, or route condition
becomes invalid, the PED withholds further affected capabilities or
the Finality Sink rejects their use.
11.12.32. WF-12.32 — Capability Consumption and Replay Protection
Where the applicable capability is single-use or usage-bounded,
FS-1211 performs or coordinates the required protected usage-state
operation.
A representative capability-state record comprises:
capability_id;
candidate_act_digest;
authorized_source_workload;
authorized_destination_service;
authorized_route;
usage_limit;
remaining_uses;
protected_state_version;
status.
A single-use capability is prevented from authorizing another
incompatible consequential operation after valid consumption.
A replayed capability is rejected when its protected usage state no
longer permits effectuation.
Das Expires 19 April 2027 [Page 509]
Internet-Draft Protected AI Execution Finality October 2026
Where multiple uses are expressly authorized, the applicable counter,
window, or session restrictions remain enforceable.
The selected implementation determines how consumption is coordinated
across distributed proxy instances.
11.12.33. WF-12.33 — Distributed Service-Mesh State Consistency
Where different proxies, gateways, protected authorities, or Finality
Sinks participate in the same operation, the system maintains the
required consistency of authorization information.
Such information may include:
(a) Candidate Act identity;
(b) source workload identity;
(c) destination service identity;
(d) authorized route;
(e) policy epoch;
(f) revocation epoch;
(g) validation-record digest;
(h) capability identifier;
(i) protected usage state; and
(j) designated Finality Sink.
The participating components exchange authenticated commitments or
consult protected state sufficient to establish the required
correspondence.
Where required consistency cannot be established, the affected
operation remains blocked.
The architecture does not assume that globally instantaneous
synchronization or one distributed database transaction is necessary
for every deployment.
The actual implementation provides consistency appropriate to its
claimed authorization and effectuation guarantees.
Das Expires 19 April 2027 [Page 510]
Internet-Draft Protected AI Execution Finality October 2026
11.12.34. WF-12.34 — Policy Updates and Revocation During Runtime
During an active cloud-agent session, protected policy state may
change.
Examples include:
(a) revocation of an agent's service permission;
(b) removal of a permitted destination service;
(c) restriction of an authorized network route;
(d) withdrawal of a credential scope;
(e) invalidation of an approved workflow;
(f) expiry of a service authorization;
(g) workload identity revocation; and
(h) update of the applicable protected policy epoch.
PED-1207 updates or consults the corresponding protected
authorization state.
Where the changed condition is mandatory for the operation, an
earlier capability cannot independently authorize effectuation under
incompatible current state.
The Finality Sink verifies the current conditions required by the
applicable authorization.
A live network-policy update and an operation-specific protected
capability check are distinguishable mechanisms.
Updating a policy does not itself establish that a particular
Candidate Act has obtained valid finality authorization.
11.12.35. WF-12.35 — Credential and Privileged Connector Integration
Where the service-mesh operation requires protected credential
application, the request may be routed through an authorized
credential broker or privileged connector.
The workload may possess only a restricted credential reference.
Das Expires 19 April 2027 [Page 511]
Internet-Draft Protected AI Execution Finality October 2026
The corresponding protected authorization determines whether the
actual credential-mediated operation is permitted.
Where a separate credential-effectuation Finality Sink is required,
that boundary verifies the applicable capability before protected
credential use.
The service-mesh Finality Sink may separately verify the
authorization required for network transmission.
The credential broker cannot independently enlarge the permitted
service operation merely because it possesses a reusable credential.
The detailed protected grant-state and connector mechanisms may be
implemented as described in WF-04 and WF-05.
11.12.36. WF-12.36 — Crash, Retry, and Incomplete Service Effectuation
The system maintains fail-closed behavior across applicable cloud
infrastructure failures.
Interception failure: An unavailable mandatory interception component
does not create authorization to use an uncontrolled alternate path.
PED failure: The Candidate Act remains non-effective if required
protected authorization cannot be established.
Evidence-commitment failure: No valid corresponding capability
becomes available when mandatory commitment has failed.
Capability-delivery failure: The protected system consults committed
state before determining whether an existing capability can be
recovered or retired.
Proxy failure before transmission: The system determines whether the
proposed operation remains eligible for authorized continuation.
Failure after possible transmission: The operation may enter an
indeterminate completion state when downstream delivery or execution
cannot be established.
A timeout does not necessarily prove that the downstream service
failed to perform the operation.
The system does not automatically replay an operation when doing so
could cause an unauthorized duplicate consequence.
Das Expires 19 April 2027 [Page 512]
Internet-Draft Protected AI Execution Finality October 2026
Where available, authenticated operation identifiers, downstream
idempotency services, completion receipts, or receiving-side Finality
Sinks may support reconciliation.
11.12.37. WF-12.37 — Illustrative Cloud-Native Service-Mesh
Implementation
In one concrete implementation, an AI agent executes within a
Kubernetes pod.
The agent prepares an HTTPS request to an approved internal
enterprise service.
The pod is configured so that the governed outbound request must pass
through an enforcement-controlled service-mesh sidecar or egress
gateway.
The request is intercepted and maintained in a pending, Non-Effective
State.
DC-1204 constructs a canonical descriptor identifying the source
workload, source container, authenticated destination service,
requested HTTP operation, target resource, payload digest, authorized
route, policy epoch, nonce, and designated Finality Sink.
PED-1207 obtains the applicable Authority Object.
The PED validates the required workload, destination, operation,
approved workflow, route, policy, revocation, and freshness
predicates.
The protected mechanism performs the required authorization-state
operation and commits a corresponding AVR, LAVR, or equivalent
protected validation record.
CR-1210 then makes available a scoped Execution-Enabling Capability.
The sidecar or egress gateway obtains the actual operation and
verifies its correspondence with the capability.
If the required predicates succeed, the controlled interface forwards
the approved request.
If the destination service, source workload, required route, or
policy state differs from the authorized context, the operation is
refused.
Das Expires 19 April 2027 [Page 513]
Internet-Draft Protected AI Execution Finality October 2026
The AI workload cannot transmit the prohibited request through an
accessible alternate path that bypasses mandatory verification.
This illustrates infrastructure-level control of the transition from
AI computation to cloud service effectuation.
11.12.38. WF-12.38 — Illustrative Service Substitution Attack
An AI workload receives permission to invoke an approved
documentation-retrieval service.
The authorized capability identifies the permitted service identity
and operation scope.
The workload subsequently attempts to use the same capability to
transmit information to a different internal service.
The infrastructure Finality Sink authenticates the actual destination
identity.
The destination does not satisfy the capability's mandatory service
binding.
The request is refused.
The earlier approval remains insufficient because the proposed
externally effective operation differs from the validated operation.
11.12.39. WF-12.39 — Illustrative Alternative Network-Path Attack
An agent executes in a container whose normal application traffic is
routed through a protected service-mesh proxy.
The agent attempts to bypass the proxy by invoking a different
networking interface or using another available execution route.
In the specified non-bypassable implementation, the alternative route
is either inaccessible or controlled by an equivalent required
Finality Sink.
The unverified operation therefore cannot produce the governed
network effect.
If an unrestricted bypass path remains accessible and can effectuate
the governed operation, the implementation does not satisfy the
specified bypass-prevention guarantee.
Das Expires 19 April 2027 [Page 514]
Internet-Draft Protected AI Execution Finality October 2026
This test distinguishes mere proxy deployment from mandatory
execution-finality mediation.
11.12.40. WF-12.40 — Alternative Technical Implementations
The protected cloud-native architecture may be implemented through
different infrastructure arrangements.
Sidecar implementation: A sidecar proxy intercepts governed service
traffic and verifies the applicable capability.
Service-mesh gateway implementation: A shared gateway performs the
controlled effectuation function for multiple workloads.
Ingress-controller implementation: An ingress component verifies
protected authorization before admitting a governed service
invocation.
Egress-controller implementation: A controlled egress interface
verifies the required capability before allowing outbound
transmission.
API-gateway implementation: An API gateway verifies the capability
against the actual operation and service identity.
Workload-proxy implementation: A protected proxy associated with an
individual workload enforces authorized destinations and operations.
Message-bus implementation: A controlled message-publication
interface prevents unauthorized message delivery.
Cloud-network-controller implementation: An infrastructure-controlled
forwarding component enforces scoped network capability conditions.
Hardware-assisted implementation: A SmartNIC, DPU, or other protected
network device enforces the required forwarding authorization for the
governed network effect.
Single-node implementation: One protected node performs
authorization, state handling, evidence commitment, capability
release, and local Finality Sink verification.
Distributed implementation: The PED and Finality Sink operate on
separate authenticated nodes.
The choice of deployment substrate does not remove the requirement
for actual control over the governed effectuation path.
Das Expires 19 April 2027 [Page 515]
Internet-Draft Protected AI Execution Finality October 2026
11.12.41. WF-12.41 — Failure and Fail-Closed Conditions
The system refuses the governed cloud operation when any mandatory
condition is absent, invalid, expired, revoked, inconsistent,
replayed, or unverifiable.
Non-limiting denial conditions include:
(a) unavailable required interception;
(b) invalid Candidate Act Descriptor;
(c) missing Authority Object;
(d) source workload identity mismatch;
(e) source container mismatch where required;
(f) unauthorized destination service;
(g) unauthorized operation class;
(h) invalid behavioral-logic condition;
(i) unauthorized network route;
(j) invalid mTLS session binding where required;
(k) stale policy epoch;
(l) invalid revocation state;
(m) expired capability;
(n) replayed nonce;
(o) exhausted capability usage;
(p) failed protected-state transition;
(q) failed validation-evidence commitment;
(r) missing Execution-Enabling Capability;
(s) invalid capability authentication;
(t) Finality Sink mismatch;
Das Expires 19 April 2027 [Page 516]
Internet-Draft Protected AI Execution Finality October 2026
(u) route substitution;
(v) service substitution; or
(w) inability to establish required current authorization conditions.
The operation may remain held, be denied, be quarantined, or be
submitted to a separately authorized review procedure.
No mandatory failure condition creates unrestricted fallback
authority.
11.12.42. WF-12.42 — PHOSITA Verification and Negative Tests
A person having ordinary skill in cloud security, service-mesh
engineering, container orchestration, network policy, distributed
authorization, cryptography, or protected execution may verify the
architecture through controlled tests.
Test 1 — Authorized service request: Submit a request matching all
required protected identity, operation, route, state, and capability
bindings. The Finality Sink permits the scoped operation.
Test 2 — Missing capability: Present a governed request without the
required Execution-Enabling Capability. The Finality Sink refuses
effectuation.
Test 3 — Source workload substitution: Reuse a capability through
another workload where workload identity is mandatory. Verification
fails.
Test 4 — Container identity mismatch: Present the capability from an
incompatible container context where that binding is required. The
operation is refused.
Test 5 — Service identity substitution: Redirect the operation to
another destination service. Required service identity verification
fails.
Test 6 — Route substitution: Change the requested network route to
one outside the permitted authorization scope. The Finality Sink
refuses the request.
Test 7 — mTLS session mismatch: Attempt to reuse a session-bound
capability through an incompatible authenticated transport session.
Verification fails.
Das Expires 19 April 2027 [Page 517]
Internet-Draft Protected AI Execution Finality October 2026
Test 8 — Expired capability: Present the capability after its
validity interval. The operation remains non-effective.
Test 9 — Revocation: Revoke a mandatory authorization condition
before effectuation. The affected request is refused.
Test 10 — Policy epoch mismatch: Advance the required policy epoch
and present an incompatible earlier capability. The Finality Sink
refuses the operation.
Test 11 — Replay: Re-present a consumed single-use capability.
Protected usage-state verification fails.
Test 12 — Direct network bypass: Attempt to transmit the governed
operation outside the designated proxy. The route is blocked or
subjected to equivalent finality verification.
Test 13 — Unauthorized host network: Attempt to access unrestricted
host networking from the workload. The governed effect remains
subject to the required enforcement boundary.
Test 14 — Alternative service interface: Attempt the same
consequential service operation through another accessible interface.
The implementation prevents unmediated effectuation.
Test 15 — Request mutation: Change a mandatory application operation
or payload parameter after protected validation. Actual-operation
correspondence fails.
Test 16 — Destination resolution change: Substitute an unauthorized
destination during connection establishment. The applicable
destination predicate fails.
Test 17 — Session reuse: Reuse an authenticated connection for an
operation outside the permitted scope. The subsequent operation is
refused.
Test 18 — Concurrent capability use: Attempt concurrent use of a
single-use authorization. Protected state prevents unauthorized
duplicate consumption.
Test 19 — PED failure: Make the required protected authorization
component unavailable. The governed operation remains blocked.
Test 20 — Proxy failure: Disable the mandatory proxy component. The
system does not enable an unprotected alternative route.
Das Expires 19 April 2027 [Page 518]
Internet-Draft Protected AI Execution Finality October 2026
Test 21 — Evidence failure: Interrupt required validation-evidence
commitment. No valid corresponding capability is made available.
Test 22 — Unauthorized service-to-service continuation: Authorize one
service call and attempt an unrelated downstream operation without
its separately required authority. The corresponding downstream
Finality Sink refuses the operation.
Test 23 — Message-bus publication: Attempt publication to a topic
outside the permitted scope. Protected finality verification fails.
Test 24 — Credential scope substitution: Attempt to apply a
credential outside the validated service and operation scope. The
governed credential or network effect is refused.
Test 25 — Multi-tenant scope mismatch: Present a capability bound to
another tenant where tenant identity is a mandatory authorization
condition. Verification fails.
Test 26 — Crash after possible delivery: Interrupt a request after
potential downstream receipt. Recovery records or reconciles the
uncertain outcome rather than automatically creating another
unrestricted execution attempt.
Test 27 — Distributed authorization consistency: Issue a capability
at one protected authority node and verify it at another node. The
Finality Sink rejects inconsistent mandatory policy, state, or
operation bindings.
Test 28 — Single-node verification: Implement the authorization and
Finality Sink functions within one protected node and verify that the
governed operation still cannot bypass required capability-dependent
effectuation.
Test 29 — Service-mesh configuration tampering: Attempt to modify
ordinary routing configuration to create an unauthorized path. The
protected infrastructure prevents the governed effect from bypassing
finality verification.
Test 30 — Receiving-side consequence distinction: Permit an
authorized source-side transmission while withholding separate
authorization required for a downstream database commit. The
receiving-side operation remains non-effective.
Das Expires 19 April 2027 [Page 519]
Internet-Draft Protected AI Execution Finality October 2026
The tests may be implemented using controlled cloud workloads, test
containers, temporary service meshes, mock authenticated services,
programmable network routes, synthetic message-bus endpoints,
protected authorization-state services, network fault injection,
policy-state changes, and capability-verification instrumentation.
The tests establish only those guarantees demonstrated by the
particular implementation and its defined threat model.
11.12.43. WF-12.43 — Claim-Specific Technical Support
Enforcement Point 58 — Protected Service-Mesh Effectuation System
The workflow describes:
(a) CW-1201 hosting the cloud AI workload;
(b) IM-1202 providing infrastructure-level interception through a
service-mesh proxy, sidecar proxy, gateway, or equivalent controller;
(c) interception of service, API, network, message-bus, database-
request, or downstream workflow operations before governed
effectuation;
(d) PED-1207 validating Candidate Act Descriptor, workload identity,
service identity, authorized destination, route, approved behavioral
logic, policy state, and revocation state;
(e) EV-1209 establishing protected validation evidence;
(f) CR-1210 releasing the scoped Execution-Enabling Capability; and
(g) FS-1211 verifying that capability before permitting the governed
operation.
Enforcement Point 59 — Service Identity and Session Binding
WF-12.20 and WF-12.21 provide explicit capability binding to the
required workload, container, destination service, route,
authenticated transport session, policy epoch, revocation epoch,
nonce, and validation-record reference.
Enforcement Point 60 — Service-Mesh Bypass Prevention
WF-12.3 through WF-12.5 and WF-12.26 provide mandatory interception
and alternative-path prevention.
Das Expires 19 April 2027 [Page 520]
Internet-Draft Protected AI Execution Finality October 2026
The implementation blocks or equivalently mediates accessible paths
capable of producing the same governed effect.
Enforcement Point 61 — Fail-Closed Route and Policy Mismatch
WF-12.27 and WF-12.28 provide refusal conditions for expired
capability, revoked authority, unauthorized service substitution,
source-workload mismatch, destination mismatch, replay, and route
inconsistency.
11.12.44. WF-12.44 — Technical Effect
The workflow establishes a protected execution-finality relationship
between:
(a) an AI workload generating a Candidate Act;
(b) mandatory cloud infrastructure interception;
(c) maintenance of the operation in a Non-Effective State;
(d) construction of a canonical Candidate Act Descriptor;
(e) authenticated workload and destination-service identity;
(f) protected validation of operation, behavior, destination, route,
policy, revocation, and freshness predicates;
(g) required protected-state handling;
(h) protected validation-evidence commitment;
(i) scoped Execution-Enabling Capability availability;
(j) independent Finality Sink verification against the actual cloud
operation;
(k) controlled transmission, forwarding, service invocation, or
message delivery; and
(l) fail-closed withholding when any mandatory authorization
condition fails.
The architecture prevents a cloud-hosted AI workload from converting
mere service identity, network connectivity, possession of a
credential, membership in a service mesh, or ordinary application
permission into unrestricted authority to produce a governed
consequential operation.
Das Expires 19 April 2027 [Page 521]
Internet-Draft Protected AI Execution Finality October 2026
The same protected finality principle may be implemented through a
sidecar, gateway, service mesh, network controller, API proxy,
message interceptor, or another infrastructure enforcement component,
provided the actual effectuation path is controlled.
A service-mesh proxy is not automatically a protected Finality Sink
merely because it forwards traffic.
The required security property arises when the infrastructure
component cannot permit the governed operation without verifying the
applicable scoped Execution-Enabling Capability and mandatory
protected authorization conditions.
Computation is not authority to act.
Service authentication is not authorization of every service
operation.
Network connectivity is not authority to produce an external effect.
An upstream policy decision does not replace the required Finality
Sink verification.
11.13. WF-13 — Protected Pre-Computation Model Admission, Algorithmic
Logic Fingerprint Verification, Runtime Behavioral Governance,
Model-Loader Authorization, and Separate Downstream Execution
Finality
11.13.1. WF-13.1 — Technical Purpose
This embodiment describes a computer-implemented protected
computation-admission architecture configured to govern whether a
proposed artificial-intelligence computation may enter a designated
model-execution environment.
The system controls proposed inference operations, agent requests,
tool-enabled model computations, retrieval-enabled invocations,
memory-enabled computations, model-loading operations, and other
governed computation-start events.
The technical objective is to prevent a requesting agent,
application, orchestration component, or model client from initiating
a governed model computation merely because it possesses an
application programming interface credential, authenticated session,
service permission, or general authorization to access a computing
platform.
Das Expires 19 April 2027 [Page 522]
Internet-Draft Protected AI Execution Finality October 2026
A proposed computation request is classified as a Candidate
Computation Admission Act and retained in a Pending Admission State.
The request does not cross the governed computation-admission
boundary unless a Protected Governance Domain validates the
applicable computation context against an Approved Algorithmic Logic
Fingerprint Condition and makes available a corresponding
computation-start authorization artifact.
The admission component verifies the artifact against the actual
proposed computation and applicable protected state.
This embodiment distinguishes:
(a) authentication of the requesting client;
(b) authorization of the proposed computation;
(c) integrity and approval of the selected model, workflow, and
configuration;
(d) issuance or validation of computation-start authority;
(e) verification at the computation-admission boundary;
(f) runtime behavioral governance following admission; and
(g) separate authorization of consequential external operations
generated by the admitted computation.
Authorization to begin computation does not automatically confer
authority to produce an externally effective tool call, network
transmission, credential use, file modification, financial operation,
deployment, or physical actuation.
The architecture is applicable to model-serving systems, inference
gateways, AI orchestration platforms, autonomous-agent runtimes,
protected model loaders, accelerator runtimes, retrieval-augmented
generation systems, enterprise model services, and other AI computing
environments.
11.13.2. WF-13.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
CE-1301 — Computation Requesting Environment
Das Expires 19 April 2027 [Page 523]
Internet-Draft Protected AI Execution Finality October 2026
A requesting application, AI agent, model client, orchestrator,
service, workflow, or other component configured to propose a
governed computation.
RA-1302 — Request Admission Component
An enforcement-controlled interface positioned between CE-1301 and a
designated model-execution service, configured to intercept proposed
computation requests before the governed computation-start boundary.
HQ-1303 — Pending Admission Holding Mechanism
A controlled staging facility maintaining a proposed computation
request or authenticated representation in a Pending Admission State.
DC-1304 — Governed Computation-Context Descriptor Component
A mechanism configured to construct or verify a machine-readable
representation of the proposed computation request and its relevant
model, policy, workflow, purpose, and execution context.
PGD-1305 — Protected Governance Domain
A protected authorization environment configured to authenticate
applicable authority information, evaluate the Approved Algorithmic
Logic Fingerprint Condition, validate required protected state, and
control computation-start authorization.
PGD-1305 may constitute a Protected Enforcement Domain (PED) or a
Cryptographically Isolated Enforcement Domain (CIED), according to
the particular security requirements.
ALF-1306 — Approved Algorithmic Logic Fingerprint Verification
Component
A protected or authenticated mechanism configured to determine
whether the proposed model, workflow, execution configuration, or
logic class satisfies the required approved ALF condition.
AS-1307 — Protected Computation Authority Store
A protected or authenticated mechanism maintaining approved model
identities, ALF conditions, policy epochs, revocation information,
workload permissions, authorized computation scopes, and other
required authority state.
EV-1308 — Computation Validation-Evidence Component
Das Expires 19 April 2027 [Page 524]
Internet-Draft Protected AI Execution Finality October 2026
An optional or required protected mechanism, according to the
particular embodiment, configured to generate or commit computation-
admission evidence.
CR-1309 — Computation-Start Authorization Component
A protected mechanism configured to generate, derive, validate,
register, or make available the computation-start authorization
artifact.
MA-1310 — Model Admission Finality Sink
An enforcement-controlled interface configured to verify the
computation-start authorization artifact before permitting the
governed computation to begin.
ML-1311 — Model Loader and Runtime Activation Component
A model loader, model registry interface, checkpoint loader, adapter
loader, accelerator-runtime initializer, or equivalent component
controlling admission of the approved model state into the governed
computation environment.
RB-1312 — Runtime Behavioral Measurement Component
A mechanism configured to collect or construct a Runtime Behavioral
Descriptor (RBD) or other applicable runtime observations after
admission or during a permitted computation.
EF-1313 — Downstream Execution-Finality Subsystem
A separately applicable protected finality arrangement configured to
govern externally effective Candidate Acts generated by an admitted
computation.
OS-1314 — Protected Computation Outcome-State Component
A mechanism maintaining admission decisions, protected state, denial
conditions, authorization usage, revocation, and applicable
computation-outcome information.
The components may be colocated or distributed across protected
software services, model-serving gateways, confidential computing
environments, secure enclaves, hardware controllers, or other
suitable execution substrates.
Das Expires 19 April 2027 [Page 525]
Internet-Draft Protected AI Execution Finality October 2026
11.13.3. WF-13.3 — Establishment of the Computation Admission Boundary
Before a governed model computation begins, the system establishes a
technical admission boundary between the requesting component and the
corresponding model-execution service.
The admission boundary may be positioned at:
(a) a model-serving gateway;
(b) an inference request broker;
(c) a protected model loader;
(d) an authenticated model registry;
(e) an accelerator-runtime initializer;
(f) a checkpoint-loading interface;
(g) an adapter activation interface;
(h) a protected orchestration service;
(i) a model-compute scheduling interface; or
(j) an equivalent computation-admission point.
Where the model-execution service is governed by mandatory pre-
computation authorization, the requesting environment cannot
independently bypass the admission component using another accessible
model-loading, inference, or compute-initialization path.
A model-serving endpoint that merely performs optional application-
level checks does not establish non-bypassable admission when an
alternative unrestricted execution path remains available.
The actual implementation identifies the computation-start interfaces
within the protected admission scope and controls their effectuation.
11.13.4. WF-13.4 — Identification of Governed Computation-Start Events
The system identifies computation events that require protected
admission.
Such events may include:
(a) initiating an inference request;
Das Expires 19 April 2027 [Page 526]
Internet-Draft Protected AI Execution Finality October 2026
(b) invoking an agentic model workflow;
(c) loading a protected model checkpoint;
(d) activating an adapter or model extension;
(e) beginning a tool-enabled model computation;
(f) initiating retrieval-enabled inference;
(g) initiating memory-enabled inference;
(h) activating a model-serving runtime;
(i) selecting an approved model variant;
(j) allocating governed accelerator execution resources; or
(k) another defined computation-start event.
The protected policy determines which operations are subject to
admission control.
An operation that has already begun computation cannot be described
as prevented at computation start merely because a subsequent runtime
check rejects its later output.
Pre-computation admission and downstream execution-finality control
are therefore separate, identifiable functions.
11.13.5. WF-13.5 — Generation of the Candidate Computation Admission
Act
CE-1301 generates or submits a proposed computation request.
The request may contain:
request_id;
requesting_client_identity;
agent_identity;
requested_model;
requested_model_version;
proposed_workflow;
Das Expires 19 April 2027 [Page 527]
Internet-Draft Protected AI Execution Finality October 2026
authorized_purpose_reference;
tool_configuration;
retrieval_configuration;
memory_configuration;
policy_context;
requested_compute_endpoint;
session_context.
The proposed operation is classified as Candidate Computation
Admission Act CCA-1315.
The request represents an intention to initiate computation but does
not independently establish the protected authority required to begin
the governed operation.
11.13.6. WF-13.6 — Pending Admission State
RA-1302 intercepts CCA-1315 before the corresponding computation-
start effect.
The request is placed into HQ-1303.
An illustrative pending admission record comprises:
operation_id;
requesting_identity;
requested_model_reference;
requested_workflow_reference;
computation_context_reference;
requested_compute_endpoint;
policy_epoch;
nonce;
created_at;
Das Expires 19 April 2027 [Page 528]
Internet-Draft Protected AI Execution Finality October 2026
status = PENDING_ADMISSION.
The request remains pending until the required computation-start
authorization conditions are satisfied.
An application-layer timeout, operator preference, orchestration
approval, or permissive fallback does not independently establish
protected computation-start authority.
If a mandatory authorization condition cannot be established, the
admission component refuses or continues holding the requested
computation.
11.13.7. WF-13.7 — Governed Computation-Context Descriptor
DC-1304 constructs a Governed Computation-Context Descriptor
representing the proposed computation request.
The descriptor identifies at least the requested model or model
class, applicable execution purpose, proposed workflow or policy
context, and the protected computation-admission boundary.
Additional fields may include:
requesting_agent_identity;
tenant_identity;
model_identifier;
model_version;
checkpoint_digest;
adapter_digest;
workflow_class;
tool_policy_reference;
retrieval_policy_reference;
memory_policy_reference;
safety_policy_reference;
authorized_purpose;
Das Expires 19 April 2027 [Page 529]
Internet-Draft Protected AI Execution Finality October 2026
jurisdiction_condition;
requested_compute_endpoint;
authorized_destination_context;
policy_epoch;
revocation_epoch;
nonce;
expiry;
admission_sink_identity.
The particular claim and Authority Object determine which additional
fields are mandatory.
The descriptor is distinguishable from the computation request itself
and from the computation-start authorization artifact.
11.13.8. WF-13.8 — Canonical Computation Descriptor Formation
In an illustrative cryptographic implementation, the computation
descriptor is encoded deterministically.
A non-limiting representation is:
Dcompute = Canon_v(ID, MODEL, WORKFLOW, PURPOSE, POLICY, CONTEXT,
EPOCH, SINK)
where:
Dcompute denotes the canonical computation-context descriptor;
Canon_v denotes deterministic encoding under version v;
ID denotes the requesting identity or workload context;
MODEL denotes the requested model and required model measurements;
WORKFLOW denotes the proposed computational workflow;
PURPOSE denotes the authorized execution purpose;
POLICY denotes the applicable tool, retrieval, memory, and safety-
policy context;
Das Expires 19 April 2027 [Page 530]
Internet-Draft Protected AI Execution Finality October 2026
CONTEXT denotes required runtime and computation-environment
parameters;
EPOCH denotes the protected policy or authorization-state version;
and
SINK denotes the designated computation-admission boundary.
An illustrative descriptor digest is:
hCompute = H("DAS-COMPUTE-v1" || Encode(Dcompute))
where H denotes an approved cryptographic hash function and Encode
denotes the selected deterministic serialization.
The particular hash function, encoding procedure, and domain-
separation label are implementation choices.
Where exact descriptor correspondence is required, the authorizing
component and admission verifier employ compatible field definitions
and canonicalization rules.
11.13.9. WF-13.9 — Acquisition of Applicable Computation Authority
PGD-1305 obtains the applicable authority information from AS-1307 or
another authenticated authority source.
The authority may define:
(a) authorized requesting clients;
(b) permitted model identities;
(c) approved model versions;
(d) approved checkpoint or adapter state;
(e) permitted ALF conditions;
(f) authorized workflow classes;
(g) permitted computation purpose;
(h) tool and retrieval restrictions;
(i) memory-access conditions;
(j) required safety-policy configuration;
Das Expires 19 April 2027 [Page 531]
Internet-Draft Protected AI Execution Finality October 2026
(k) jurisdiction or tenant restrictions;
(l) policy and revocation requirements;
(m) nonce or usage restrictions; and
(n) permitted computation-admission boundaries.
The Protected Governance Domain verifies the required authenticity,
scope, and current validity of the authority information.
A requesting application cannot independently create protected
authorization merely by naming a permitted model or presenting a
self-declared approved configuration.
11.13.10. WF-13.10 — Approved Algorithmic Logic Fingerprint Condition
ALF-1306 evaluates whether the proposed computation context satisfies
the applicable Approved Algorithmic Logic Fingerprint Condition.
The ALF may represent an approved:
(a) model identity;
(b) model checkpoint;
(c) adapter configuration;
(d) orchestration workflow;
(e) tool-access graph;
(f) retrieval policy;
(g) memory policy;
(h) safety-policy configuration;
(i) computational pipeline; or
(j) approved class of algorithmic behavior.
The Protected Governance Domain determines whether the proposed
configuration corresponds to an approved fingerprint, measurement, or
permitted logic class.
Das Expires 19 April 2027 [Page 532]
Internet-Draft Protected AI Execution Finality October 2026
ALF validation may use an exact digest match, approved class
membership, authenticated measurement, permitted composite condition,
or another machine-verifiable correspondence rule supported by the
embodiment.
Successful model identity verification alone does not necessarily
prove that the entire workflow satisfies its required approved ALF
condition.
The applicable policy establishes which measurements are mandatory.
11.13.11. WF-13.11 — Composite ALF and Multi-Component Model
Configuration
In an embodiment employing a Composite ALF, the authorization may
depend upon several aspects of the computational environment.
A composite measurement may represent:
(a) base model identity;
(b) checkpoint digest;
(c) adapter state;
(d) system or instruction configuration;
(e) tool policy;
(f) retrieval policy;
(g) memory policy;
(h) safety policy; and
(i) orchestration workflow.
An illustrative composite reference is:
CompositeALF = H(Encode(ModelState, AdapterState, ToolPolicy,
RetrievalPolicy, MemoryPolicy, SafetyPolicy, WorkflowState))
This formula is a non-limiting implementation example.
The required Composite ALF may include fewer or additional
measurements according to the applicable authorized model condition.
Das Expires 19 April 2027 [Page 533]
Internet-Draft Protected AI Execution Finality October 2026
If a mandatory configuration measurement changes, the previously
approved ALF condition must be reevaluated according to the protected
policy.
The system does not assume that identical base-model weights imply
identical authorization for every possible tool, retrieval, memory,
or safety configuration.
11.13.12. WF-13.12 — Authorized Purpose and Context Validation
The Protected Governance Domain evaluates whether the proposed
computation remains within the authorized purpose and execution
scope.
Where applicable, an Algorithmic Intent Fingerprint (AIF) represents
the permitted operational intent.
The validation may determine whether:
(a) the proposed computation purpose is authorized;
(b) the model class is permitted for that purpose;
(c) the requesting tenant is within scope;
(d) the intended destination or output context is permitted;
(e) the proposed tool or retrieval configuration remains within the
authorized workflow; and
(f) the applicable jurisdictional requirements are satisfied.
An approved model may be authorized for one purpose but not for
another.
Authorization to perform one class of computation does not
automatically authorize every related or subsequent model invocation.
11.13.13. WF-13.13 — Protected Pre-Computation Authorization Predicate
PGD-1305 evaluates the required admission predicates.
An illustrative conjunctive predicate is:
Vadmit = Pidentity AND Pmodel AND PALF AND Ppurpose AND Pcontext AND
Pstate
where:
Das Expires 19 April 2027 [Page 534]
Internet-Draft Protected AI Execution Finality October 2026
Vadmit denotes the protected computation-admission decision;
Pidentity verifies the requesting identity;
Pmodel verifies the permitted model or model class;
PALF verifies the Approved Algorithmic Logic Fingerprint Condition;
Ppurpose verifies the authorized computation purpose;
Pcontext verifies the required workflow, policy, and execution-
context conditions; and
Pstate verifies applicable policy, revocation, freshness, nonce, and
protected-state conditions.
Where approved alternative or threshold conditions apply, the
Protected Governance Domain evaluates the authorized combination
rather than requiring every possible predicate to be conjunctive.
Failure of any mandatory predicate prevents successful computation-
start authorization.
11.13.14. WF-13.14 — Protected Authorization-State Handling
Where required by the embodiment, PGD-1305 performs protected
authorization-state operations before making computation-start
authority available.
Such operations may include:
(a) verification of the current policy epoch;
(b) consultation of required revocation state;
(c) reservation of a computation-admission grant;
(d) consumption or registration of a nonce;
(e) checking the computation quota;
(f) registration of a model-admission identifier;
(g) protection against replay; or
(h) another mandatory state transition.
Das Expires 19 April 2027 [Page 535]
Internet-Draft Protected AI Execution Finality October 2026
Where a computation grant has a restricted usage allowance, the
protected mechanism coordinates state updates to prevent unauthorized
duplicate admission.
If the required protected-state operation fails, the system does not
treat the proposed computation as authorized.
11.13.15. WF-13.15 — Computation-Admission Validation Evidence
Where the applicable embodiment requires protected validation
evidence, EV-1308 generates or commits an authenticated record
representing the computation-admission decision.
A non-limiting record comprises:
validation_record_id;
computation_descriptor_digest;
approved_alf_reference;
authority_object_reference;
validated_model_reference;
policy_epoch;
nonce;
protected_state_reference;
admission_boundary_id;
decision;
protected_authentication.
The record may be implemented as an authenticated validation
artifact, sealed record, protected commitment, AVR, LAVR, or
equivalent mechanism where the corresponding embodiment supports it.
Where evidence commitment is a prerequisite to computation-start
authority, the required evidence is committed before, or atomically
with, availability of the corresponding authorization artifact.
Das Expires 19 April 2027 [Page 536]
Internet-Draft Protected AI Execution Finality October 2026
enforcement point 54 itself does not independently impose every
protected receipt or state-consumption limitation used in the broader
execution-finality architecture. Such additional conditions apply
where required by the selected embodiment.
11.13.16. WF-13.16 — Computation-Start Authorization Artifact
Upon successful satisfaction of the applicable protected computation-
admission conditions, CR-1309 generates, validates, or makes
available the computation-start authorization artifact.
The artifact may contain or securely reference:
authorization_id;
computation_descriptor_digest;
approved_alf_reference;
authorized_model_identifier;
checkpoint_reference;
adapter_reference;
authorized_workflow_scope;
tool_scope;
retrieval_scope;
memory_scope;
authorized_purpose;
tenant_scope;
policy_epoch;
revocation_reference;
nonce;
expiry;
admission_boundary_id.
In an illustrative authenticated implementation:
Das Expires 19 April 2027 [Page 537]
Internet-Draft Protected AI Execution Finality October 2026
Cstart = Sign_skPGD(Encode(hCompute, ALFref, ModelRef, Scope, Epoch,
Nonce, Expiry, Sink))
where:
Cstart denotes the computation-start authorization artifact;
Sign_skPGD denotes signature generation under a key protected by the
governance domain;
hCompute denotes the canonical computation descriptor digest;
ALFref denotes the approved ALF reference;
ModelRef denotes the authorized model identity;
Scope denotes the permitted computation scope;
Epoch denotes the applicable protected policy epoch;
Nonce denotes the required freshness value;
Expiry denotes the authorized validity limit; and
Sink denotes the protected computation-admission boundary.
The selected implementation may instead use a MAC-authenticated
record, protected capability table, sealed authorization reference,
hardware enablement condition, or equivalent machine-verifiable
authorization mechanism.
The artifact is not an unrestricted credential for arbitrary model
execution.
11.13.17. WF-13.17 — Model and Workflow Measurement Binding
in the implementation described by enforcement point 55, the
computation-start authorization artifact is bound to at least one of:
(a) model identifier;
(b) checkpoint hash;
(c) adapter digest;
(d) approved workflow class;
(e) tool-policy reference;
Das Expires 19 April 2027 [Page 538]
Internet-Draft Protected AI Execution Finality October 2026
(f) retrieval-policy reference;
(g) memory-policy reference;
(h) safety-policy reference;
(i) purpose class;
(j) jurisdiction condition;
(k) tenant identity;
(l) destination context;
(m) policy epoch; or
(n) nonce.
The Protected Governance Domain validates the mandatory bindings
before issuing or approving the artifact.
The request-admission component verifies the applicable bindings
before permitting computation.
Where the selected model or workflow configuration differs materially
from the authorized state, the original artifact does not
independently authorize execution.
11.13.18. WF-13.18 — Independent Computation-Admission Verification
MA-1310 receives or obtains the computation-start authorization
artifact and the proposed computation request.
Before forwarding or admitting the request, the admission interface
verifies:
(a) artifact authenticity;
(b) required computation-descriptor correspondence;
(c) approved ALF condition;
(d) requested model identity;
(e) required checkpoint or adapter identity;
(f) permitted workflow scope;
Das Expires 19 April 2027 [Page 539]
Internet-Draft Protected AI Execution Finality October 2026
(g) authorized purpose;
(h) required policy and revocation state;
(i) applicable nonce and expiry;
(j) usage or replay restrictions; and
(k) designated computation-admission boundary.
The admission interface determines whether the actual proposed
computation matches the authorized computation context.
It does not rely solely upon an earlier assertion that the requesting
client is authenticated or that its API credential is valid.
11.13.19. WF-13.19 — Computation Admission Verification Predicate
An illustrative verification expression is:
PermitCompute = Auth(Cstart) AND Match(Cstart,Dactual) AND
ALFValid(Cstart,Mactual) AND ScopeValid(Cstart,Xactual) AND
StateValid(Cstart,S) AND SinkValid(Cstart,F)
where:
PermitCompute denotes permission to begin the governed computation;
Cstart denotes the computation-start authorization artifact;
Dactual denotes the actual computation-context descriptor;
Mactual denotes the selected model or required workflow measurement;
Xactual denotes the relevant execution context;
S denotes applicable protected authorization state; and
F denotes the designated computation-admission interface.
Auth verifies artifact authenticity.
Match verifies required descriptor correspondence.
ALFValid verifies the approved model or workflow condition.
ScopeValid verifies the authorized computation scope.
Das Expires 19 April 2027 [Page 540]
Internet-Draft Protected AI Execution Finality October 2026
StateValid verifies required policy, revocation, freshness, and usage
conditions.
SinkValid verifies the designated admission boundary.
The computation request is admitted only if every mandatory predicate
succeeds.
11.13.20. WF-13.20 — Protected Model-Loader Admission
in the implementation described by enforcement point 56, MA-1310 is
associated with ML-1311.
The model loader may comprise:
(a) a model registry;
(b) a model checkpoint loader;
(c) an adapter loader;
(d) an accelerator-runtime initializer;
(e) a protected model activation controller;
(f) a model-serving runtime;
(g) an authenticated model-state manager; or
(h) an equivalent loading or activation interface.
The model weights, adapters, execution state, or accelerator-resident
model state are not activated for the governed computation until the
computation-start authorization artifact verifies against the
approved model state.
The implementation distinguishes loading or staging model bytes from
activating them for the governed computation.
A model may be stored or prepared without necessarily being
authorized for use in the particular execution context.
11.13.21. WF-13.21 — Model Loader Verification Sequence
In a non-limiting implementation, the protected model loader performs
the following sequence.
First, it receives or resolves the proposed model identity.
Das Expires 19 April 2027 [Page 541]
Internet-Draft Protected AI Execution Finality October 2026
Second, it obtains the applicable checkpoint, adapter, or required
configuration measurements.
Third, it retrieves or verifies the corresponding approved ALF
condition.
Fourth, it obtains the computation-start authorization artifact.
Fifth, it verifies the artifact's authenticity and mandatory
computation-context bindings.
Sixth, it checks required current policy, revocation, freshness, and
usage state.
Seventh, it compares the actual model state against the approved
model condition.
Eighth, it permits activation of the approved model state only if all
mandatory authorization conditions succeed.
If the required conditions fail, the governed model-activation
interface remains disabled or refuses the requested computation.
The system does not treat the presence of model weights in memory as
sufficient evidence of authorization to execute them.
11.13.22. WF-13.22 — Accelerator and Model-State Activation
In an accelerator-backed implementation, ML-1311 may control the
transition from prepared model state into executable model state.
The model may be staged in storage, host memory, protected loading
buffers, or another non-active representation before admission.
Upon successful verification, the model loader permits the required
activation operation.
Possible implementations include:
(a) an authenticated model-loader authorization hook;
(b) protected runtime initialization;
(c) a model-registry admission controller;
(d) an accelerator scheduling interface;
(e) a protected checkpoint activation procedure;
Das Expires 19 April 2027 [Page 542]
Internet-Draft Protected AI Execution Finality October 2026
(f) an adapter-activation interface; or
(g) an equivalent model-computation enablement mechanism.
Where model activation or computation admission requires a hardware-
controlled condition, the implementation must actually enforce that
condition at the selected boundary.
Software admission alone does not automatically provide protection
against a privileged attacker able to bypass that software boundary.
11.13.23. WF-13.23 — Runtime Behavioral Descriptor Formation
After successful admission, RB-1312 may collect governance-relevant
runtime information associated with the computation.
An RBD may represent:
(a) tools invoked;
(b) retrieval endpoints accessed;
(c) memory resources used;
(d) workflow transitions;
(e) policy branches selected;
(f) connector usage;
(g) generated tool requests;
(h) resource-access patterns;
(i) external content consumed;
(j) model or configuration changes; and
(k) other applicable runtime observations.
The RBD represents observed runtime behavior.
An RBD measuring behavior during a computation cannot ordinarily
serve as evidence of behavior that has not yet occurred at the
initial computation-start boundary.
Accordingly, pre-computation ALF verification and subsequent runtime
RBD validation are temporally distinguishable operations.
Das Expires 19 April 2027 [Page 543]
Internet-Draft Protected AI Execution Finality October 2026
The initial admission may depend on previously available runtime
evidence, but observations arising only after the computation begins
are evaluated at an appropriate later checkpoint or effectuation
boundary.
11.13.24. WF-13.24 — Runtime Behavioral Drift and Continued Governance
Where the computation is subject to runtime governance, the protected
system may compare the observed RBD against the authorized ALF, AIF,
workflow envelope, or other applicable protected predicates.
Relevant deviations may include:
(a) invocation of an unauthorized tool;
(b) retrieval from an unapproved data source;
(c) use of a prohibited memory scope;
(d) unexpected connector access;
(e) material change in the approved workflow;
(f) unauthorized model or adapter modification;
(g) violation of the permitted purpose; or
(h) an incompatible protected policy-state change.
If a mandatory runtime condition fails, the system may restrict
further computation admission, revoke a bounded runtime
authorization, withhold subsequent operation capabilities, or apply
another supported fail-closed enforcement action.
A runtime behavioral alarm does not automatically prove that an
earlier external effect was prevented.
The effect of the monitoring decision depends upon the actual
controlled boundary and whether the corresponding consequential
operation was still non-effective when enforcement occurred.
11.13.25. WF-13.25 — Pre-Computation and Runtime Authorization
Separation
The system distinguishes at least three authorization stages.
Pre-computation admission: Whether the model and workflow may begin
the governed computation under the applicable Approved ALF Condition.
Das Expires 19 April 2027 [Page 544]
Internet-Draft Protected AI Execution Finality October 2026
Runtime governance: Whether the continuing computation remains within
required behavioral, policy, workflow, and operational constraints.
External execution finality: Whether a particular consequential act
resulting from the computation may become effective.
The same Protected Governance Domain may participate in multiple
stages.
However, successful authorization at an earlier stage does not
automatically discharge a separate mandatory authorization condition
at a later stage.
This distinction prevents approval of a model or computation from
becoming unrestricted authority over external tools, services,
credentials, data, or physical systems.
11.13.26. WF-13.26 — Separate Downstream Execution Authority
in the implementation described by enforcement point 57, EF-1313
governs externally effective operations generated after successful
computation admission.
A model may be admitted to execute inference and subsequently
generate:
(a) a tool invocation;
(b) an external API request;
(c) a credential-mediated operation;
(d) a network transmission;
(e) a persistent file modification;
(f) a database commit;
(g) a software deployment;
(h) a payment instruction; or
(i) another consequential operation.
The generated operation constitutes a separate Candidate Act.
Das Expires 19 April 2027 [Page 545]
Internet-Draft Protected AI Execution Finality October 2026
The computation-start authorization artifact does not independently
substitute for the required protected execution-finality authority
applicable to that Candidate Act.
The separate operation remains subject to protected validation,
applicable protected-state and evidence conditions, scoped execution-
capability availability, and Finality Sink verification as required
by its corresponding embodiment.
11.13.27. WF-13.27 — Downstream Finality Verification Sequence
For an admitted model computation that generates a protected external
operation, the system may perform the following sequence.
First, the model computes an output or tool instruction.
Second, the output is classified as a Candidate Act.
Third, an appropriate interception component prevents the act from
becoming effective.
Fourth, an effectuation-specific Candidate Act Descriptor is
constructed.
Fifth, the applicable PED validates the required operation,
authority, purpose, destination, policy, provenance, and runtime
predicates.
Sixth, the PED performs required protected-state operations.
Seventh, required protected validation evidence is committed.
Eighth, the corresponding scoped execution capability is made
available.
Ninth, the applicable Finality Sink verifies the capability against
the actual proposed consequential operation.
Tenth, only the validated and authorized effect is permitted.
The downstream Finality Sink may comprise a network interface,
credential broker, tool executor, storage commit controller, API
gateway, deployment controller, payment switch, actuator, or another
protected effectuation boundary.
The required security relationship is determined by the particular
downstream operation and claim.
Das Expires 19 April 2027 [Page 546]
Internet-Draft Protected AI Execution Finality October 2026
11.13.28. WF-13.28 — Example: Approved Model, Unauthorized Tool
Operation
An AI agent requests permission to execute an approved model using an
authorized checkpoint and permitted inference workflow.
The Protected Governance Domain verifies the approved ALF condition
and makes available a valid computation-start authorization artifact.
The admission component verifies the artifact.
The model begins computation.
During execution, the model generates a request to transmit
confidential information to an unauthorized external endpoint.
Although the model was correctly admitted to compute, the proposed
transmission is a separate Candidate Act.
The network finality subsystem constructs the effectuation-relevant
descriptor.
The protected authority determines that the requested destination
violates a mandatory authorization predicate.
The required network capability is withheld.
The network Finality Sink does not permit the unauthorized
transmission.
The initial model-admission authorization remains distinct from the
failed downstream execution authorization.
11.13.29. WF-13.29 — Example: Unauthorized Adapter Substitution
An application proposes a computation using an approved base model.
The computation-start artifact is bound to the base model and an
approved adapter digest.
After authorization, the requesting environment attempts to
substitute a different adapter before activation.
The model loader obtains the actual adapter measurement.
The measurement does not match the mandatory authorized adapter
state.
Das Expires 19 April 2027 [Page 547]
Internet-Draft Protected AI Execution Finality October 2026
The computation-admission verification fails.
The governed model activation is refused unless a new valid
authorization permits the changed model context.
An approved base model does not independently authorize arbitrary
adapter substitutions where adapter state is a required condition.
11.13.30. WF-13.30 — Example: Retrieval-Policy Modification
A governed retrieval-enabled model request is authorized under an
approved retrieval policy.
The approved ALF condition includes the applicable retrieval-policy
reference.
Before computation admission, the requester attempts to replace the
retrieval configuration with a broader source set.
The Protected Governance Domain or admission verifier determines that
the actual proposed computation context no longer satisfies the
required approved policy condition.
The computation-start artifact is withheld or rejected.
Where retrieval configuration changes during an already admitted
computation, the system applies the corresponding runtime or
retrieval-boundary authorization rather than assuming that the
original admission check automatically governs every later retrieval.
11.13.31. WF-13.31 — Authorization Refresh and Policy Epoch Changes
The applicable model or computation authority may change before or
during a governed session.
Such events may include:
(a) revocation of an approved model;
(b) withdrawal of an approved checkpoint;
(c) invalidation of an adapter;
(d) modification of required safety-policy state;
(e) change in a permitted tool graph;
(f) revocation of a requesting tenant;
Das Expires 19 April 2027 [Page 548]
Internet-Draft Protected AI Execution Finality October 2026
(g) expiry of a computation authorization; or
(h) advancement of the protected policy epoch.
Where a current authorization-state check is mandatory, a stale
computation-start artifact cannot independently authorize another
computation-start event.
Where an active computation is subject to continued runtime or
downstream effectuation controls, the system enforces the
corresponding current-state conditions at the specified checkpoints.
Revocation cannot retroactively prevent computation that has already
occurred.
11.13.32. WF-13.32 — Replay and Unauthorized Reuse Prevention
Where computation-start authorization is nonce-bound, usage-bounded,
session-bound, or otherwise restricted, the admission mechanism
verifies the corresponding protected state.
An illustrative authorization record comprises:
authorization_id;
computation_descriptor_digest;
approved_alf_reference;
authorized_model_identity;
permitted_session;
policy_epoch;
nonce;
remaining_uses;
expiry;
status.
An artifact authorizing one computation event does not automatically
authorize an unrelated event when the relevant authorization
conditions prohibit reuse.
Das Expires 19 April 2027 [Page 549]
Internet-Draft Protected AI Execution Finality October 2026
Where a single-use computation-start artifact is required, the
protected state mechanism prevents unauthorized concurrent or
repeated admission using the same grant.
Where bounded repeated use is expressly permitted, the corresponding
validity and usage limits are enforced.
11.13.33. WF-13.33 — Crash, Restart, and Recovery
The system distinguishes failures before and after governed
computation admission.
Failure before protected authorization: The request remains pending
or denied. No valid computation-start artifact becomes available for
an incomplete mandatory authorization procedure.
Failure after authorization but before admission: The protected
system evaluates the committed authorization and usage state before
restoring or reissuing the artifact.
Failure during model activation: The model loader determines whether
activation completed and whether renewed admission verification is
required.
Failure after computation begins: A restart or replacement runtime
must satisfy the applicable model, policy, authorization, and
freshness conditions before any newly governed computation-start
event proceeds.
Failure after a downstream consequential operation: The downstream
operation follows its own protected outcome and recovery procedure.
A restart does not automatically reestablish previously revoked,
expired, or consumed execution authority.
The exact recovery guarantees depend upon the implemented protected
state and the controlled model-execution interface.
11.13.34. WF-13.34 — Alternative Structural Implementations
The protected computation-admission relationship may be implemented
through several technical arrangements.
Inference-gateway implementation: An authenticated gateway verifies
computation-start authority before forwarding a request to a model
service.
Das Expires 19 April 2027 [Page 550]
Internet-Draft Protected AI Execution Finality October 2026
Protected model-loader implementation: The loader prevents activation
of unauthorized model state.
Model-registry implementation: A protected registry admission service
restricts selection or activation of model artifacts.
Accelerator-runtime implementation: A controlled runtime initializer
requires the corresponding computation-start authorization before
admitting the governed model computation.
Confidential-computing implementation: Protected authorization and
model-state verification operate within a confidential VM, enclave,
or protected computation environment according to its security
properties.
Single-node implementation: The requesting workload, protected
governance function, and admission verifier are colocated while
retaining their required functional authorization separation.
Distributed implementation: The Protected Governance Domain and
model-execution service operate on separate nodes and exchange
authenticated computation-start authorization information.
Multi-model implementation: A protected admission gateway authorizes
specified models or model classes according to their individual
authority and approved ALF requirements.
Runtime-governed implementation: Pre-computation admission is
supplemented by RBD checks and separately enforced consequential-
operation finality.
Different substrates need not provide identical protection against
privileged host compromise, hardware compromise, rollback, model
substitution, or service bypass.
The implementation must enforce the actual security properties
required under the specified enforcement profile.
11.13.35. WF-13.35 — Failure and Fail-Closed Conditions
The request-admission component refuses a governed computation-start
operation when a mandatory condition is absent, invalid, expired,
revoked, inconsistent, replayed, or unverifiable.
Non-limiting denial conditions include:
(a) missing computation-start authorization artifact;
Das Expires 19 April 2027 [Page 551]
Internet-Draft Protected AI Execution Finality October 2026
(b) invalid artifact authentication;
(c) unauthorized requesting identity;
(d) invalid model identity;
(e) unauthorized checkpoint;
(f) adapter digest mismatch;
(g) failed Approved ALF Condition;
(h) unauthorized workflow class;
(i) invalid tool-policy reference;
(j) unauthorized retrieval policy;
(k) invalid memory-policy condition;
(l) invalid safety-policy condition;
(m) unauthorized purpose;
(n) jurisdiction mismatch where required;
(o) tenant identity mismatch;
(p) unauthorized computation endpoint;
(q) stale policy epoch;
(r) invalid revocation state;
(s) expired or replayed nonce;
(t) exhausted usage state;
(u) failed mandatory protected-state operation;
(v) failed required validation-evidence commitment;
(w) computation-descriptor mismatch;
(x) admission-sink mismatch; or
(y) unavailable required protected verification.
Das Expires 19 April 2027 [Page 552]
Internet-Draft Protected AI Execution Finality October 2026
The system may retain the request in Pending Admission State, deny
admission, quarantine an unapproved model artifact, or use a
separately authorized recovery procedure.
No mandatory failure condition creates authority to begin computation
through an unprotected fallback.
11.13.36. WF-13.36 — PHOSITA Verification and Negative Tests
A person having ordinary skill in machine-learning systems, model-
serving infrastructure, trusted computing, AI orchestration,
distributed authorization, cryptography, or accelerator runtimes may
verify the described architecture through controlled tests.
Test 1 — Approved model admission: Submit a request satisfying all
mandatory model, ALF, purpose, policy, and artifact conditions. The
admission component permits the governed computation.
Test 2 — Missing authorization artifact: Present a valid client
credential without computation-start authorization. Admission is
refused.
Test 3 — Unauthorized model: Request a model outside the approved
class. The required ALF or model authorization condition fails.
Test 4 — Checkpoint substitution: Replace the approved checkpoint
with an unauthorized checkpoint. Mandatory model-state
correspondence fails.
Test 5 — Adapter substitution: Change the required adapter digest
after authorization. Admission is refused.
Test 6 — Tool-policy mismatch: Present a workflow containing an
unauthorized tool configuration. The applicable ALF condition fails.
Test 7 — Retrieval-policy mismatch: Widen a mandatory approved
retrieval policy. Protected validation refuses the incompatible
computation.
Test 8 — Memory-policy mismatch: Change the mandatory memory-access
configuration outside authorized scope. Admission fails.
Test 9 — Safety-policy modification: Substitute a configuration that
no longer satisfies the approved safety-policy condition. The
authorization is rejected.
Test 10 — Purpose mismatch: Request an otherwise approved model for
an unauthorized purpose. Admission fails.
Das Expires 19 April 2027 [Page 553]
Internet-Draft Protected AI Execution Finality October 2026
Test 11 — Tenant substitution: Reuse a tenant-bound artifact from
another tenant. The applicable identity or scope predicate fails.
Test 12 — Computation endpoint substitution: Attempt use of the
authorization at a different protected admission boundary where
boundary binding is mandatory. Verification fails.
Test 13 — Policy epoch change: Present an artifact bound to an
incompatible previous policy epoch. Admission is refused.
Test 14 — Revoked model: Revoke a mandatory model approval.
Subsequent governed admission is denied.
Test 15 — Expired artifact: Present an expired computation-start
authorization. Admission fails.
Test 16 — Replay: Reuse a consumed single-use authorization artifact.
Protected usage verification rejects unauthorized reuse.
Test 17 — Concurrent admission: Submit concurrent requests against
one restricted authorization. The protected mechanism prevents
unauthorized duplicate consumption.
Test 18 — Model-loader bypass: Attempt activation through an
alternative model-loading interface. The operation is blocked or
subjected to equivalent required admission verification.
Test 19 — Unverified checkpoint loading: Stage model weights without
valid authorization and attempt to activate them. The governed
activation boundary refuses the operation.
Test 20 — ALF measurement mismatch: Modify a mandatory computation-
logic measurement. Protected validation fails.
Test 21 — Runtime behavioral drift: After valid admission, cause a
mandatory runtime behavioral condition to fail. The applicable
runtime enforcement withholds further affected authorization.
Test 22 — Unauthorized downstream network request: Admit an approved
model, then generate an unauthorized external request. The separate
network Finality Sink refuses the operation.
Test 23 — Unauthorized downstream tool call: Admit an approved
computation, then propose an unauthorized consequential tool
operation. The tool-execution Finality Sink refuses the operation.
Das Expires 19 April 2027 [Page 554]
Internet-Draft Protected AI Execution Finality October 2026
Test 24 — Credential-use separation: Verify that computation-start
authorization alone does not enable unrestricted protected credential
use.
Test 25 — Crash before authorization: Interrupt the mandatory
protected admission procedure before commitment. No valid
corresponding artifact becomes available.
Test 26 — Crash after authorization: Interrupt the admission
interface after successful protected authorization. Recovery
consults the corresponding protected state rather than granting
unrestricted reuse.
Test 27 — Policy update during computation: Change a mandatory
authorization condition and verify the appropriate runtime or
subsequent effectuation enforcement.
Test 28 — Single-node admission: Implement protected admission within
one node and verify that requesting computation cannot bypass the
mandatory authorization boundary.
Test 29 — Distributed admission: Issue computation-start authority at
a protected governance service and verify it at a remote model-
serving interface. Invalid bindings are rejected.
Test 30 — Downstream finality distinction: Successfully authorize
model computation while independently withholding a separate
Candidate Act capability. Confirm that computation admission does
not cause the unauthorized external effect.
These tests may be performed using controlled inference services,
mock AI agents, protected model-loader hooks, test registries,
synthetic checkpoints, adapter substitutions, authenticated policy
stores, programmable admission interfaces, runtime-behavior
instrumentation, and fault injection.
The tests establish only the security properties demonstrated by the
actual implementation and its stated threat model.
11.13.37. WF-13.37 — Claim-Specific Technical Support
Enforcement Point 54 — Protected Pre-Computation Model Admission
System
This workflow provides:
(a) CE-1301 representing a requesting client, AI agent, or
application;
Das Expires 19 April 2027 [Page 555]
Internet-Draft Protected AI Execution Finality October 2026
(b) RA-1302 positioned before a model-execution service;
(c) interception of governed computation requests;
(d) DC-1304 constructing the governed computation-context descriptor;
(e) PGD-1305 validating the Approved Algorithmic Logic Fingerprint
Condition;
(f) CR-1309 generating or validating the computation-start
authorization artifact;
(g) HQ-1303 retaining the request in Pending Admission State;
(h) MA-1310 refusing admission when required artifact or context
verification fails; and
(i) separation of ordinary client authentication from protected
computation-start authority.
Enforcement Point 55 — Model and Workflow Measurement Binding
WF-13.7 through WF-13.11 and WF-13.17 provide the required model,
checkpoint, adapter, workflow, policy, purpose, jurisdiction, tenant,
destination, epoch, or nonce bindings.
Enforcement Point 56 — Protected Model-Loader Admission
WF-13.20 through WF-13.22 describe the model-loader, registry,
checkpoint, adapter, or accelerator-runtime admission mechanism and
require the computation-start artifact to verify before the governed
model state is activated.
Enforcement Point 57 — Separate Downstream Execution Authority
WF-13.25 through WF-13.28 establish the separation between
authorization to begin computation and authorization to produce a
subsequent consequential effect.
The downstream Candidate Act is subject to its own protected finality
sequence.
11.13.38. WF-13.38 — Technical Effect
The workflow establishes a protected computation-admission dependency
between:
(a) generation of a proposed model computation;
Das Expires 19 April 2027 [Page 556]
Internet-Draft Protected AI Execution Finality October 2026
(b) mandatory interception before the governed computation-start
boundary;
(c) retention in Pending Admission State;
(d) construction of a governed computation-context descriptor;
(e) authentication of applicable computation authority;
(f) protected verification of the Approved Algorithmic Logic
Fingerprint Condition;
(g) required purpose, workflow, model-state, policy, revocation, and
freshness checks;
(h) computation-start authorization artifact generation or
validation;
(i) independent verification at the computation-admission boundary;
(j) controlled admission of the authorized model or computation;
(k) applicable runtime behavioral governance; and
(l) separate execution-finality authorization of downstream
consequential Candidate Acts.
The system prevents a client or autonomous agent from treating an API
credential, authenticated session, approved model name, or ordinary
inference permission as sufficient authority to initiate a governed
computation without satisfying the required approved ALF and
computation-start authorization conditions.
The stronger model-loader embodiment prevents the governed model
weights, checkpoint, adapter, or accelerator state from becoming
active for the requested computation without successful protected
admission verification.
The downstream finality subsystem separately determines whether a
generated tool invocation, network request, file modification,
credential operation, or other consequential act may become
effective.
Computation is not authority to act.
Authentication is not protected computation-start authorization.
Das Expires 19 April 2027 [Page 557]
Internet-Draft Protected AI Execution Finality October 2026
An approved model does not automatically authorize every execution
configuration.
Authorization to compute is not authorization to produce an external
consequence.
11.14. WF-14 — Protected Model-Path and Downstream Effectuation-Path
Dual Authorization, Inference-to-Act Context Binding, Streaming
Output Control, Multi-Sink Classification, and Remote Finality
Verification
11.14.1. WF-14.1 — Technical Purpose
This embodiment describes a computer-implemented execution-finality
architecture providing two distinguishable protected authorization
functions associated with artificial-intelligence computation and
consequential operations derived from that computation.
A first protected authorization function controls admission of a
proposed inference or agent-computation request through a governed
model-access path.
A second protected authorization function controls whether a
particular consequential operation generated, selected, prepared, or
derived from the admitted computation is permitted to cross its
applicable execution-finality boundary.
The architecture prevents authorization of a model invocation from
being treated as sufficient authorization for subsequent network
transmission, tool invocation, credential use, database modification,
payment execution, software deployment, persistent storage operation,
actuator command, or other externally effective operation.
The first protected boundary verifies computation-admission authority
associated with the requested model, workload, execution purpose, and
approved computation context.
The second protected boundary treats each governed consequential
operation as a Candidate Act and maintains it in a Non-Effective
State until an applicable Protected Enforcement Domain validates its
operation-specific authorization context, commits required protected
validation evidence, and releases or makes available a scoped
execution capability.
A downstream Finality Sink verifies the scoped capability against the
actual operation and current applicable authorization state before
permitting effectuation.
Das Expires 19 April 2027 [Page 558]
Internet-Draft Protected AI Execution Finality October 2026
The two authorization functions may be implemented through separate
components, colocated protected services, one protected node, or
distributed infrastructure.
However, successful verification at the model-access gate does not
replace the separately required verification at the downstream
Finality Sink.
The architecture further addresses:
(a) binding of computation-admission context to a downstream
Candidate Act;
(b) protection against unauthorized conversion of model output into
execution authority;
(c) streaming model outputs and partially generated tool commands;
(d) continued withholding of buffered operations after model-access
interruption;
(e) classification of multiple distinct consequential operations and
their respective Finality Sinks;
(f) independent receiving-side verification;
(g) protection against time-of-check and time-of-use substitution;
(h) protected authorization-state changes, revocation, and replay;
and
(i) failure, crash recovery, and uncertain downstream completion.
11.14.2. WF-14.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
ME-1401 — Model-Execution Environment
A model-serving system, inference environment, model runtime, agent-
computation service, accelerator-backed model engine, or equivalent
component configured to receive and process governed model-
computation requests.
MG-1402 — Protected Model-Access Gate
Das Expires 19 April 2027 [Page 559]
Internet-Draft Protected AI Execution Finality October 2026
An enforcement-controlled interface positioned on the governed path
to ME-1401, configured to verify computation-admission authority
before permitting a model invocation.
AC-1403 — Computation-Admission Authorization Component
A protected component configured to authenticate the requesting
workload, requested model, approved execution context, purpose, and
required policy state.
AR-1404 — Protected Computation-Admission Record
A protected or authenticated record representing authorization of a
particular computation, model context, or bounded computation
session.
AE-1405 — Agent or Tool Execution Environment
An AI-agent runtime, orchestration process, tool execution
environment, application, workflow controller, or associated
computational component configured to receive model outputs and
prepare consequential operations.
OC-1406 — Protected Operation-Classification Component
A mechanism configured to identify externally effective operations
arising from admitted computation and represent those operations as
Candidate Acts.
HQ-1407 — Non-Effective Candidate Act Holding Mechanism
An enforcement-controlled mechanism configured to hold a proposed
consequential operation before it crosses the applicable effectuation
boundary.
DC-1408 — Candidate Act Descriptor Component
A mechanism configured to obtain or construct the effectuation-
relevant descriptor of a downstream Candidate Act.
PED-1409 — Protected Enforcement Domain
A protected authorization component configured to validate the
concrete operation, applicable authority, current protected state,
intended effectuation boundary, and other required predicates.
PS-1410 — Protected Authorization-State Store
Das Expires 19 April 2027 [Page 560]
Internet-Draft Protected AI Execution Finality October 2026
A protected mechanism maintaining applicable operation grants, policy
epochs, revocation state, nonces, capability usage, validation
commitments, and computation-to-operation authorization references.
EV-1411 — Protected Evidence-Commitment Component
A mechanism configured to generate or commit operation-specific
protected validation evidence before, or atomically with,
availability of the required operation-specific execution capability.
CR-1412 — Scoped Execution-Capability Component
A protected mechanism configured to generate, register, derive,
release, or otherwise make available the required operation-specific
execution capability.
SC-1413 — Inference-to-Act Context Binding Component
A mechanism configured to associate an admitted model-computation
context with a subsequently generated Candidate Act without
converting admission authority into effectuation authority.
SM-1414 — Streaming Output and Partial-Action Controller
An enforcement-controlled mechanism configured to classify and hold
partial outputs, tool-call fragments, command representations, and
completed or bounded consequential operations.
FC-1415 — Effectuation Boundary Classification Component
A mechanism configured to identify the appropriate Finality Sink or
Finality Sinks for each consequential operation in an agentic
workflow.
FS-1416 — Downstream Finality Sink
An effectuation interface configured to independently verify the
operation-specific capability before allowing the Candidate Act to
become effective.
RV-1417 — Remote Actual-Operation Verification Component
An optional or required remote-side verifier configured to
reconstruct or verify the Candidate Act presented at a receiving
service, gateway, database, payment system, connector, or physical-
control interface.
OS-1418 — Protected Operation-Outcome Component
Das Expires 19 April 2027 [Page 561]
Internet-Draft Protected AI Execution Finality October 2026
A mechanism maintaining pending, authorized, reserved, denied,
confirmed-effective, revoked, expired, or indeterminate effectuation
states.
RC-1419 — Revocation and Authorization-Consistency Component
A protected mechanism configured to maintain or verify the required
relationship among computation-admission state, downstream authority,
capability usage, policy epochs, and applicable Finality Sinks.
The described components may be implemented within one physical node
or across multiple authenticated and protected components.
The model-access gate and downstream Finality Sink remain separate
enforcement functions even where their software or hardware
implementations are integrated.
11.14.3. WF-14.3 — Establishment of Two Governed Authorization
Boundaries
The system establishes two authorization boundaries.
Boundary A — Model-Computation Admission Boundary
Boundary A controls whether a particular model or agent computation
may begin through the governed model-execution path.
The model-access gate verifies computation-admission authority before
permitting the requested inference or computation.
Boundary B — Consequential Effectuation Boundary
Boundary B controls whether an operation generated, selected, or
prepared from the admitted computation may become externally
effective.
The downstream Finality Sink verifies the operation-specific
execution capability before effectuation.
The boundaries control different technical events.
Successful admission at Boundary A permits only the governed
computation within its authorized scope.
It does not automatically enable a subsequent operation at Boundary
B.
Das Expires 19 April 2027 [Page 562]
Internet-Draft Protected AI Execution Finality October 2026
Likewise, interruption or revocation at Boundary A does not by itself
establish that an already generated operation has been denied,
consumed, cancelled, or prevented at Boundary B.
The system therefore requires explicit enforcement at the downstream
effectuation boundary whenever the consequential operation is subject
to protected finality.
11.14.4. WF-14.4 — Model-Path Trust Boundary
MG-1402 is positioned on a governed path to ME-1401.
The model-access gate may be implemented through:
(a) a model-serving gateway;
(b) an inference admission controller;
(c) a protected model loader;
(d) an authenticated model-access broker;
(e) an accelerator-admission controller;
(f) a protected runtime interface;
(g) a network or infrastructure controller positioned on the selected
model path; or
(h) an equivalent protected mechanism.
The requesting agent or client cannot independently bypass the
required computation-admission verification through another path
within the specified governed model-access scope.
A physical network device positioned on a model-access path is not
automatically established to control every other downstream
effectuation interface.
The implementation must identify the model paths actually governed by
the device.
Where a stronger claim requires the gate to be mandatory for all
model access within a defined environment, the implementation must
enforce that coverage rather than merely monitor one optional access
route.
Das Expires 19 April 2027 [Page 563]
Internet-Draft Protected AI Execution Finality October 2026
11.14.5. WF-14.5 — Downstream Effectuation Trust Boundary
The system separately identifies the interfaces through which the
admitted computation may produce consequential effects.
Such interfaces may include:
(a) external network egress;
(b) authenticated API invocation;
(c) tool execution;
(d) protected credential use;
(e) database commitment;
(f) payment execution;
(g) software deployment;
(h) persistent memory mutation;
(i) message delivery;
(j) actuator control;
(k) storage finalization;
(l) model-output release; or
(m) another governed effectuation interface.
Each governed operation is associated with an applicable downstream
Finality Sink.
The downstream execution path is configured so that the requesting
agent cannot cause the specified consequential effect through an
accessible alternative interface without satisfying the required
protected finality conditions.
The model-access gate may provide an earlier authorization or
monitoring control, but the actual non-bypassability of downstream
effectuation depends upon the downstream enforcement arrangement.
Das Expires 19 April 2027 [Page 564]
Internet-Draft Protected AI Execution Finality October 2026
11.14.6. WF-14.6 — Generation of the Proposed Inference Request
A requesting agent, application, or other computational component
prepares a proposed inference request.
A non-limiting request contains:
inference_request_id;
requesting_workload_id;
requested_model_id;
model_version;
approved_execution_context;
requested_computation_purpose;
workflow_reference;
tool_configuration_reference;
policy_epoch;
session_reference;
model_access_gate_id.
The proposed request is presented to MG-1402.
The request does not independently authorize computation merely
because the agent has generated it or possesses a valid application-
level authentication credential.
11.14.7. WF-14.7 — Protected Computation-Admission Validation
AC-1403 validates the mandatory computation-admission predicates.
These may include:
(a) authenticated workload identity;
(b) authorized model identity;
(c) permitted inference operation;
(d) approved execution purpose;
Das Expires 19 April 2027 [Page 565]
Internet-Draft Protected AI Execution Finality October 2026
(e) required ALF or model-configuration condition;
(f) applicable workflow scope;
(g) protected policy epoch;
(h) revocation state;
(i) nonce or freshness; and
(j) permitted model-access boundary.
An illustrative predicate is:
Vadmission = Pworkload AND Pmodel AND Ppurpose AND Pcontext AND
Pstate
where:
Vadmission denotes the protected computation-admission result;
Pworkload verifies requesting workload identity;
Pmodel verifies the requested model;
Ppurpose verifies the authorized computation purpose;
Pcontext verifies the approved computation context; and
Pstate verifies the required current authorization state.
Additional predicates may apply according to the particular
embodiment.
Where any mandatory predicate fails, the protected model-access gate
refuses the governed computation request.
11.14.8. WF-14.8 — Protected Computation-Admission Record
Following successful admission authorization, the system may generate
or maintain a Protected Computation-Admission Record AR-1404.
in the implementation described by enforcement point 69, the record
comprises:
(a) model identity;
(b) workload identity;
Das Expires 19 April 2027 [Page 566]
Internet-Draft Protected AI Execution Finality October 2026
(c) approved execution context;
(d) policy epoch; and
(e) authorization-state identifier.
Additional fields may include:
computation_id;
model_configuration_digest;
approved_alf_reference;
authorized_purpose;
session_id;
admission_time;
nonce;
expiry;
model_access_gate_id;
protected_authentication.
The record is authenticated or maintained under applicable protected-
state control.
The record represents the authorization conditions established for
the admitted computation.
It is not treated as a general execution capability authorizing
arbitrary external operations.
11.14.9. WF-14.9 — Admission Record Authentication and Binding
In an illustrative cryptographic implementation, the computation-
admission record may be represented as:
Radmit = AuthRecord(ModelID, WorkloadID, Context, Epoch, AuthStateID,
SessionID, Nonce)
where:
Radmit denotes the protected computation-admission record;
Das Expires 19 April 2027 [Page 567]
Internet-Draft Protected AI Execution Finality October 2026
ModelID denotes the authorized model;
WorkloadID denotes the requesting workload identity;
Context denotes the approved computation context;
Epoch denotes the applicable policy epoch;
AuthStateID denotes the protected authorization-state reference;
SessionID denotes the applicable inference-session identifier; and
Nonce denotes the required freshness value.
An illustrative authenticated commitment is:
hAdmit = H("DAS-MODEL-ADMIT-v1" || Encode(Radmit))
The commitment may be included in or referenced by a later operation-
specific authorization context.
However, possession or successful verification of hAdmit does not
independently release the capability necessary for a downstream
effect.
The cryptographic encoding is an implementation example and does not
impose one particular hash algorithm or record format on every
embodiment.
11.14.10. WF-14.10 — Controlled Model Computation
Following successful verification at MG-1402, the authorized
inference or agent computation may proceed.
ME-1401 processes the permitted computation request.
The model may generate:
(a) natural-language output;
(b) structured data;
(c) a tool invocation;
(d) an API request;
(e) a command;
Das Expires 19 April 2027 [Page 568]
Internet-Draft Protected AI Execution Finality October 2026
(f) a workflow transition;
(g) a proposed network transmission;
(h) a transaction instruction;
(i) an actuation instruction; or
(j) another output or operation representation.
The model output does not automatically acquire protected downstream
execution authority merely because the computation was validly
admitted.
Where the model output does not cross a separately governed
consequential boundary, the corresponding downstream execution-
finality procedure may not be required.
Where the output would cause a governed consequence, the appropriate
downstream authorization procedure is mandatory.
11.14.11. WF-14.11 — Identification of the Consequential Operation
OC-1406 receives or observes the model-derived operation.
The component determines whether the output:
(a) remains internal computational data;
(b) constitutes a non-effective proposal;
(c) requests a governed tool or service operation;
(d) would cause an externally effective network or storage effect;
(e) would initiate a protected transaction;
(f) would change an operational system state; or
(g) would otherwise cross a defined execution-finality boundary.
A consequential operation is classified as Candidate Act CA-1420.
The classification identifies the operation requiring protected
effectuation authorization.
A completed model computation is not automatically classified as an
externally effective operation merely because it produced data.
Das Expires 19 April 2027 [Page 569]
Internet-Draft Protected AI Execution Finality October 2026
The applicable classification depends upon the effect being
controlled.
11.14.12. WF-14.12 — Non-Effective State for the Derived Candidate Act
OC-1406 submits CA-1420 to HQ-1407.
The corresponding operation remains in a Non-Effective State.
An illustrative staging record comprises:
candidate_act_id;
source_inference_id;
source_admission_record_reference;
requesting_workload_id;
operation_class;
target_effectuation_boundary;
destination_reference;
payload_reference;
policy_epoch;
status = NON_EFFECTIVE.
The staged operation cannot produce its governed consequence while
mandatory downstream authorization remains unresolved.
The holding mechanism may retain an immutable operation
representation or authenticated digest sufficient to preserve the
effectuation-relevant parameters.
The agent's ability to formulate the operation is distinct from its
authority to release it.
11.14.13. WF-14.13 — Inference-to-Act Context Binding
in the implementation described by enforcement point 69, SC-1413
establishes a verifiable relationship between the admitted
computation and its resulting Candidate Act.
The relationship may include:
Das Expires 19 April 2027 [Page 570]
Internet-Draft Protected AI Execution Finality October 2026
(a) computation-admission record digest;
(b) model identity;
(c) workload identity;
(d) inference-session identity;
(e) approved execution context;
(f) protected policy epoch;
(g) authorization-state identifier;
(h) Candidate Act identifier; and
(i) Candidate Act Descriptor digest.
A non-limiting association is:
Bcontext = H(Encode(hAdmit, CandidateActID, hAct, ContextRef, Epoch))
where:
Bcontext denotes the inference-to-act context commitment;
hAdmit denotes the protected admission-record digest;
CandidateActID denotes the resulting Candidate Act identity;
hAct denotes the Candidate Act Descriptor digest;
ContextRef denotes applicable execution-context information; and
Epoch denotes required authorization-state context.
The protected system may verify this association as one of the
downstream authorization predicates.
The association establishes provenance or context correspondence, not
independent authority to effectuate the Candidate Act.
11.14.14. WF-14.14 — Downstream Candidate Act Descriptor
DC-1408 constructs or verifies the descriptor for CA-1420.
The descriptor identifies the operation actually proposed for
consequential execution.
Das Expires 19 April 2027 [Page 571]
Internet-Draft Protected AI Execution Finality October 2026
A non-limiting descriptor comprises:
candidate_act_id;
operation_class;
source_workload_id;
source_inference_reference;
computation_admission_reference;
source_tool_or_agent_id;
actual_operation_parameters;
destination_or_recipient;
requested_effect;
payload_digest;
authorized_purpose;
required_authority_object;
protected_policy_epoch;
revocation_epoch;
nonce;
expiry;
validation_evidence_requirement;
finality_sink_id.
The descriptor is specific to the consequential operation, not merely
to the model that generated it.
Where exact operation binding is required, effectuation-relevant
changes to the destination, payload, recipient, operation type, or
scope result in a different descriptor or failed authorization
correspondence.
Das Expires 19 April 2027 [Page 572]
Internet-Draft Protected AI Execution Finality October 2026
11.14.15. WF-14.15 — Canonical Operation Descriptor
In an illustrative implementation:
Dact = Canon_v(ACT, SOURCE, TARGET, PARAM, CONTEXT, EPOCH, SINK)
where:
Dact denotes the canonical Candidate Act Descriptor;
ACT denotes the actual proposed operation class;
SOURCE denotes the authenticated requesting workload and source
execution context;
TARGET denotes the destination, recipient, or effectuation target;
PARAM denotes effectuation-relevant parameters;
CONTEXT denotes the required inference and runtime context;
EPOCH denotes the protected authorization-state version; and
SINK denotes the designated Finality Sink identity.
An illustrative descriptor commitment is:
hAct = H("DAS-DOWNSTREAM-ACT-v1" || Encode(Dact))
where H denotes a cryptographic hash function.
The selected encoding must preserve distinctions required by the
applicable authorization.
The same relevant field interpretation is used by the protected
authorizer and downstream Finality Sink.
11.14.16. WF-14.16 — Acquisition of Operation-Specific Execution
Authority
PED-1409 obtains or resolves the Authority Object applicable to CA-
1420.
The authority may specify:
(a) authorized operation class;
(b) requesting agent or workload identity;
Das Expires 19 April 2027 [Page 573]
Internet-Draft Protected AI Execution Finality October 2026
(c) permitted recipient or destination;
(d) authorized purpose;
(e) resource or transaction scope;
(f) approved tool or connector;
(g) applicable policy epoch;
(h) revocation conditions;
(i) nonce or usage limits;
(j) required human approval;
(k) relevant provenance or runtime conditions;
(l) required inference-to-act context binding; and
(m) designated Finality Sink.
The Protected Enforcement Domain authenticates the applicable
authority information.
The computation-admission record may provide a required contextual
input.
It does not replace the separate Authority Object or protected
authorization conditions applicable to the downstream Candidate Act.
11.14.17. WF-14.17 — Protected Downstream Authorization Predicates
PED-1409 evaluates the operation-specific authorization predicates.
An illustrative conjunctive predicate is:
Vact = Poperation AND Pscope AND Ptarget AND Pcontext AND Pstate AND
Psink
where:
Vact denotes the protected downstream authorization result;
Poperation verifies the proposed consequential operation;
Pscope verifies the permitted authority and purpose scope;
Das Expires 19 April 2027 [Page 574]
Internet-Draft Protected AI Execution Finality October 2026
Ptarget verifies the intended recipient, resource, or destination;
Pcontext verifies mandatory inference-to-act and runtime context;
Pstate verifies policy, revocation, freshness, usage, and protected-
state conditions; and
Psink verifies the designated effectuation boundary.
The applicable embodiment determines which additional predicates are
required.
A valid computation-admission record may contribute to Pcontext.
However:
Vact is not inferred merely from Vadmission.
Successful model admission and successful downstream execution
authorization are separate decisions.
11.14.18. WF-14.18 — Protected Authorization-State Handling
Following successful operation-specific validation, PED-1409 performs
the protected-state operations required for CA-1420.
Such operations may include:
(a) reserving an operation-specific authorization grant;
(b) consuming or registering a nonce;
(c) updating a usage counter;
(d) verifying the applicable policy epoch;
(e) verifying current revocation state;
(f) recording the Candidate Act Descriptor digest;
(g) registering the intended Finality Sink;
(h) establishing a protected receipt reference; or
(i) performing another required protected-state transition.
Das Expires 19 April 2027 [Page 575]
Internet-Draft Protected AI Execution Finality October 2026
Where a single-use consequential operation is authorized, the
protected state mechanism prevents unauthorized concurrent reuse of
that authorization.
If a mandatory protected-state operation fails, the corresponding
execution capability is withheld.
11.14.19. WF-14.19 — Protected Operation-Specific Evidence Commitment
EV-1411 generates or commits operation-specific validation evidence.
An illustrative record contains:
receipt_id;
candidate_act_id;
candidate_act_descriptor_digest;
computation_admission_reference;
validated_authority_reference;
protected_state_transition;
policy_epoch;
revocation_epoch;
nonce;
finality_sink_id;
validation_result;
protected_authentication.
The protected evidence may comprise a LAVR, AVR, sealed validation
record, authenticated commitment, or equivalent protected
representation.
Under enforcement point 68, the required operation-specific
validation record is committed before, or atomically with,
availability of the corresponding operation-specific execution
capability.
The record is distinct from the earlier computation-admission record.
Das Expires 19 April 2027 [Page 576]
Internet-Draft Protected AI Execution Finality October 2026
An audit record created only after the external effect does not
independently satisfy the required pre-capability commitment.
11.14.20. WF-14.20 — Protected Downstream Finality Transaction
The PED establishes a protected causal dependency among successful
operation validation, required protected-state handling, validation-
evidence commitment, and capability availability.
An illustrative transaction is:
(Snext, Ract, Ready) = CommitActFinality(Dact, A, Scurrent, F)
where:
Snext denotes committed protected authorization state;
Ract denotes committed operation-specific validation evidence;
Ready denotes completion of required pre-release conditions;
Dact denotes the validated consequential operation descriptor;
A denotes applicable authenticated operation authority;
Scurrent denotes prior protected authorization state; and
F denotes the intended downstream Finality Sink.
The operation-specific capability does not become valid for
effectuation where a mandatory state or evidence dependency remains
incomplete.
This protected transaction does not necessarily require an arbitrary
remote receiving service to participate in one globally atomic
database transaction.
11.14.21. WF-14.21 — Operation-Specific Execution Capability
Following successful completion of the required protected finality
transaction, CR-1412 releases or makes available an operation-
specific execution capability.
In an illustrative cryptographic implementation:
Cact = Sign_skPED(Encode(hAct, hRact, Bcontext, Scope, Epoch, Nonce,
Expiry, F, CID))
Das Expires 19 April 2027 [Page 577]
Internet-Draft Protected AI Execution Finality October 2026
where:
Cact denotes the operation-specific execution capability;
Sign_skPED denotes authenticated capability generation under PED-
controlled key material;
hAct denotes the Candidate Act Descriptor digest;
hRact denotes the committed validation-evidence digest;
Bcontext denotes the required inference-to-act association where
applicable;
Scope denotes permitted effectuation scope;
Epoch denotes the required policy epoch;
Nonce denotes applicable freshness;
Expiry denotes capability validity;
F denotes the authorized downstream Finality Sink; and
CID denotes a capability identifier.
The capability may alternatively comprise a protected table entry,
MAC-authenticated permit, sealed handle, or hardware-controlled
execution condition.
Its non-bearer properties depend upon actual enforcement of required
scope, state, context, usage, and sink bindings.
11.14.22. WF-14.22 — Independent Downstream Finality Sink Verification
Before permitting CA-1420 to produce its consequential effect,
FS-1416 obtains the actual operation presented for effectuation.
The Finality Sink constructs or verifies the corresponding
effectuation-relevant descriptor.
The verification includes applicable checks of:
(a) capability authenticity;
(b) concrete operation correspondence;
(c) authorized destination or recipient;
Das Expires 19 April 2027 [Page 578]
Internet-Draft Protected AI Execution Finality October 2026
(d) permitted effectuation scope;
(e) required inference-to-act context;
(f) policy epoch;
(g) revocation state;
(h) nonce or expiration;
(i) validation-evidence commitment;
(j) protected usage or consumption state; and
(k) designated Finality Sink identity.
The Finality Sink refuses the operation when any mandatory
verification condition fails.
An earlier successful model-access check is not treated as a
substitute for this verification.
11.14.23. WF-14.23 — Downstream Finality Verification Predicate
An illustrative effectuation predicate is:
PermitEffect = Auth(Cact) AND Match(Cact,Dactual) AND
ScopeValid(Cact,F) AND StateValid(Cact,S) AND
EvidenceValid(Cact,Ract)
where:
PermitEffect denotes permission to effectuate the Candidate Act;
Cact denotes the scoped operation-specific capability;
Dactual denotes the operation actually presented;
F denotes the designated Finality Sink;
S denotes the required current protected authorization state; and
Ract denotes the protected operation-specific validation evidence.
Auth verifies capability authenticity.
Match verifies required exact or bounded operation correspondence.
Das Expires 19 April 2027 [Page 579]
Internet-Draft Protected AI Execution Finality October 2026
ScopeValid verifies authorized operation scope and sink identity.
StateValid verifies protected policy, revocation, freshness, and
usage conditions.
EvidenceValid verifies the required protected validation-state
commitment.
The Candidate Act becomes effective only when all mandatory
verification conditions succeed.
11.14.24. WF-14.24 — Distinction Between Model Authorization and
Effectuation Authorization
The model-access gate verifies authorization of model computation.
The downstream Finality Sink verifies authorization of a particular
consequential operation.
These mechanisms may share authenticated context or protected
authority infrastructure.
However, the following implications are not presumed:
ModelAccessAllowed does not imply EffectuationAllowed.
ModelAccessRevoked does not prove that every previously generated
Candidate Act has been cancelled.
ModelInferenceStopped does not prove that an already transmitted
consequential operation was prevented.
DownstreamCapabilityVerified does not prove that an unrelated later
Candidate Act is authorized.
Each claim of prevention depends upon the actual controlled
effectuation boundary and the required authorization state for that
boundary.
11.14.25. WF-14.25 — Revocation of Model Access
in the implementation described by enforcement point 68, revocation
of model-access authorization prevents further governed model
computation through the applicable protected model-access gate.
A revocation event may invalidate:
(a) a model-session grant;
Das Expires 19 April 2027 [Page 580]
Internet-Draft Protected AI Execution Finality October 2026
(b) a permitted model identity;
(c) an approved workflow configuration;
(d) a requesting workload's model-access scope; or
(e) another required computation-admission condition.
MG-1402 consults the required current authorization state before
permitting another governed model-computation event.
A revoked model-access grant does not independently establish the
completion status of previously generated Candidate Acts.
Those Candidate Acts remain subject to their respective downstream
authorization and Finality Sink conditions.
11.14.26. WF-14.26 — Already Generated and Buffered Candidate Acts
An AI model may have already generated a tool command, payment
instruction, API request, or other consequential operation before its
model access is interrupted.
The operation may remain buffered or queued within AE-1405 or HQ-
1407.
The interruption of additional model inference does not itself
authorize that operation for release.
The buffered operation remains a Candidate Act in a Non-Effective
State until the required downstream validation and Finality Sink
verification succeed.
Where model-access revocation is also expressly defined as a
downstream authorization predicate, the downstream authority checks
that condition.
Where the downstream authorization is independently valid under the
applicable policy, the system evaluates the Candidate Act according
to the actual governing authority rules rather than assuming that
every model-access interruption automatically revokes every other
authorization.
The two authority domains remain distinguishable.
Das Expires 19 April 2027 [Page 581]
Internet-Draft Protected AI Execution Finality October 2026
11.14.27. WF-14.27 — Model-Path Interruption and External-Effect Timing
The system distinguishes three event classes.
Event A — Inference interruption before a new operation is generated
The protected model-access gate prevents further governed model
computation, subject to its controlled path and implementation.
Event B — Inference interruption after a Candidate Act has been
generated but before effectuation
The existing Candidate Act remains governed by the downstream
Finality Sink. The model interruption does not replace required
effectuation authorization.
Event C — Inference interruption after an external operation has
already become effective
The interruption cannot retroactively prevent the completed effect.
It may restrict subsequent inference or further operations according
to the applicable enforcement mechanisms.
The architecture therefore does not claim that control over model
access alone guarantees prevention of every downstream consequence.
The actual downstream Finality Sink must control the effectuation
boundary applicable to the consequential operation.
11.14.28. WF-14.28 — Streaming Model Output and Partial-Action
Classification
in the implementation described by enforcement point 70, ME-1401 may
generate a sequence of partial outputs instead of a complete result
in one operation.
Such outputs may include:
(a) token-by-token model responses;
(b) incremental structured output;
(c) streaming tool-call arguments;
(d) partially decoded commands;
(e) partial API request bodies;
Das Expires 19 April 2027 [Page 582]
Internet-Draft Protected AI Execution Finality October 2026
(f) fragments of executable instructions;
(g) intermediate workflow instructions;
(h) partial financial operation parameters;
(i) incremental actuator-control information; or
(j) another partially generated consequential representation.
SM-1414 determines whether a fragment constitutes:
(i) non-consequential intermediate data;
(ii) an incomplete Candidate Act requiring additional assembly;
(iii) a completed bounded Candidate Act capable of producing a
consequential effect; or
(iv) an independently effective operation requiring immediate
protected authorization.
A streaming fragment is not assumed harmless merely because the model
has not finished its complete response.
11.14.29. WF-14.29 — Non-Effective Buffering of Streaming Operations
Where a partial model output may become consequential, the system
controls its progression to the effectuation interface.
An illustrative fragment record contains:
stream_id;
source_inference_id;
fragment_sequence;
fragment_reference;
fragment_digest;
candidate_act_id;
assembly_state;
authorized_effect_class;
Das Expires 19 April 2027 [Page 583]
Internet-Draft Protected AI Execution Finality October 2026
policy_epoch;
finality_sink_id;
status.
An incomplete command may remain buffered until sufficient
information exists to identify the corresponding Candidate Act.
Where a bounded fragment is itself a consequential operation, it is
separately subjected to the applicable protected finality procedure.
The system does not require every model token to obtain an
independent execution capability when those tokens remain internal
computational data.
The protected authorization granularity corresponds to the actual
governed consequence.
11.14.30. WF-14.30 — Completed or Bounded Candidate Act Formation
SM-1414 assembles or classifies streaming output into a completed or
bounded Candidate Act.
For example, a model may produce fragments forming an API request:
Fragment 1 identifies the service.
Fragment 2 identifies the requested operation.
Fragment 3 identifies the recipient.
Fragment 4 identifies the consequential payload.
The system does not permit the assembled request to be transmitted
merely because earlier fragments were generated within an admitted
model session.
The completed request is represented through a Candidate Act
Descriptor.
The applicable PED validates the concrete operation and releases the
corresponding scoped capability only after the required protected
conditions succeed.
Das Expires 19 April 2027 [Page 584]
Internet-Draft Protected AI Execution Finality October 2026
Where the authorization allows a bounded stream of repeated
operations, each independently effective unit or permitted transfer
window remains subject to its expressly authorized scope and usage
conditions.
11.14.31. WF-14.31 — Partial-Action Finality Predicate
For a governed consequential fragment or completed streaming act, an
illustrative predicate is:
PermitFragment = CompleteOrBounded(CA) AND AuthorityValid(CA) AND
CapabilityValid(CA,F) AND StateValid(CA,S)
where:
PermitFragment denotes permission to effectuate the relevant fragment
or bounded operation;
CompleteOrBounded verifies that the operation has a sufficiently
defined effectuation representation under the applicable
authorization rules;
AuthorityValid verifies the required protected authorization
predicates;
CapabilityValid verifies the applicable scoped capability at the
designated Finality Sink; and
StateValid verifies required current protected state.
An incomplete or ambiguous operation is not treated as authorized
when mandatory effectuation-relevant attributes cannot be determined.
A completed operation whose required authorization conditions fail
remains non-effective.
11.14.32. WF-14.32 — Multi-Sink Effectuation Classification
in the implementation described by enforcement point 71, an agentic
workflow may generate multiple consequential operations.
For example:
(a) a network transmission;
(b) an authenticated tool invocation;
(c) a persistent database write;
Das Expires 19 April 2027 [Page 585]
Internet-Draft Protected AI Execution Finality October 2026
(d) a payment instruction; and
(e) an infrastructure activation command.
FC-1415 identifies the relevant effectuation boundary for each
operation.
The classification may produce:
CandidateAct_1 → Network Finality Sink;
CandidateAct_2 → Tool-Execution Finality Sink;
CandidateAct_3 → Database-Commit Finality Sink;
CandidateAct_4 → Payment Finality Sink;
CandidateAct_5 → Infrastructure-Control Finality Sink.
Each operation is associated with its applicable authorization scope,
protected state, and capability-verification requirements.
The same model invocation or agent workflow may therefore produce
several independently governed Candidate Acts.
11.14.33. WF-14.33 — Multi-Sink Authorization Independence
Authorization for one Candidate Act does not automatically establish
authorization for a different operation or Finality Sink.
An illustrative condition is:
Permit(CA_i, FS_i) = ValidCapability(CA_i, FS_i) AND
RequiredStateValid(CA_i)
where:
CA_i denotes consequential operation i;
FS_i denotes the corresponding Finality Sink;
ValidCapability verifies the operation-specific capability under the
applicable sink bindings; and
RequiredStateValid verifies the required protected authorization
state.
Das Expires 19 April 2027 [Page 586]
Internet-Draft Protected AI Execution Finality October 2026
A capability permitting network transmission does not inherently
authorize a receiving database commit.
A capability permitting document signing does not inherently
authorize transmission of the signed document.
A capability permitting a tool invocation does not inherently
authorize a payment initiated by that tool.
Where a capability expressly authorizes multiple bounded phases, each
designated phase and Finality Sink enforces the applicable scope and
state conditions.
11.14.34. WF-14.34 — Receiving-Side and Remote Finality Sink
in the implementation described by enforcement point 72, FS-1416 may
comprise:
(a) a receiving service;
(b) a remote execution gateway;
(c) a protected database-commit interface;
(d) a payment execution interface;
(e) a hardware actuator;
(f) a trusted connector; or
(g) another remote or downstream consequential boundary.
The receiving-side Finality Sink obtains or reconstructs the
Candidate Act actually presented for effectuation.
The Finality Sink verifies the operation-specific capability and
required protected validation-state commitment.
It does not rely solely upon an upstream agent or gateway asserting
that the operation was approved.
The receiving-side verifier may be implemented through protected
service logic, an authenticated gateway, transaction controller,
trusted hardware interface, or other enforcement arrangement
satisfying the applicable non-bypassable requirements.
Das Expires 19 April 2027 [Page 587]
Internet-Draft Protected AI Execution Finality October 2026
11.14.35. WF-14.35 — Remote Actual-Operation Reconstruction
RV-1417 determines the effectuation-relevant attributes of the remote
operation.
These may include:
(a) actual operation type;
(b) recipient or target;
(c) destination service identity;
(d) transaction parameters;
(e) resource identifier;
(f) requested state transition;
(g) payload digest;
(h) protected authorization-state version;
(i) authorized execution scope; and
(j) receiving Finality Sink identity.
A non-limiting reconstructed descriptor is:
Dremote = Canon_v(OperationActual, RecipientActual, ParametersActual,
StateActual, SinkActual)
where:
Dremote denotes the actual remote operation descriptor;
OperationActual denotes the requested operation;
RecipientActual denotes the actual receiving entity;
ParametersActual denotes the effectuation-relevant parameters;
StateActual denotes applicable receiving-side authorization state;
and
SinkActual denotes the receiving Finality Sink.
Das Expires 19 April 2027 [Page 588]
Internet-Draft Protected AI Execution Finality October 2026
The verifier compares the reconstructed descriptor with the
applicable authenticated capability commitment.
Where exact correspondence is required, a mismatch causes denial.
Where the original authorization expressly permits bounded
variations, the verifier checks those variations against the defined
permitted scope.
11.14.36. WF-14.36 — Receiving-Side Verification Predicate
An illustrative remote verification condition is:
PermitRemote = Auth(C) AND Match(C,Dremote) AND ReceiptValid(C,R) AND
StateValid(C,Sremote) AND SinkValid(C,Fremote)
where:
PermitRemote denotes permission to perform the remote consequential
operation;
C denotes the operation-specific capability;
Dremote denotes the reconstructed actual Candidate Act Descriptor;
R denotes the required protected validation evidence;
Sremote denotes current authorization state required at the receiving
side; and
Fremote denotes the designated receiving Finality Sink.
The operation is refused where a mandatory parameter differs,
including an unauthorized:
(a) destination;
(b) recipient;
(c) operation type;
(d) protected-state version; or
(e) execution scope.
The receiving service does not automatically accept a valid-looking
upstream authorization artifact when the actual effectuation context
fails a mandatory binding.
Das Expires 19 April 2027 [Page 589]
Internet-Draft Protected AI Execution Finality October 2026
11.14.37. WF-14.37 — Illustrative End-to-End AI-Agent Transaction
In one concrete embodiment, an AI agent uses an authorized model to
prepare a financial transfer request.
The proposed model invocation is submitted to MG-1402.
The model-access gate verifies the requesting workload, model
identity, approved computation context, and required policy state.
The request is admitted to ME-1401.
The model generates a proposed transfer involving a specified
recipient, amount, currency, and payment service.
OC-1406 classifies the proposed transfer as a Candidate Act.
HQ-1407 retains the transfer in a Non-Effective State.
DC-1408 constructs an operation-specific descriptor identifying the
actual recipient, amount, currency, execution purpose, authority
scope, policy epoch, and payment Finality Sink.
PED-1409 authenticates the applicable transaction authority and
validates the mandatory predicates.
The PED performs required protected authorization-state operations.
EV-1411 commits the operation-specific validation evidence.
CR-1412 makes available a scoped execution capability bound to the
transaction and designated payment Finality Sink.
The payment execution interface independently obtains the actual
transaction information.
The payment Finality Sink verifies the scoped capability against the
recipient, amount, current protected state, evidence reference, and
required usage conditions.
Only the matching authorized transaction is permitted.
If the model subsequently loses access to the inference service, that
event does not independently establish that the payment was cancelled
or completed.
The payment interface continues to enforce the authorization rules
applicable to the actual pending transaction.
Das Expires 19 April 2027 [Page 590]
Internet-Draft Protected AI Execution Finality October 2026
11.14.38. WF-14.38 — Illustrative Model-Interruption Attack
An autonomous agent obtains valid model-access authorization.
The model generates a proposed operation to transmit protected
enterprise data.
The proposed transmission is buffered.
A security watchdog subsequently detects suspicious runtime behavior
and revokes further model access.
The model-access gate stops additional governed inference.
However, the buffered transmission remains present within the
downstream execution environment.
If that buffered transmission could reach an unrestricted network
interface, interruption of model access alone would not prove
prevention of the external transmission.
Under the specified dual-authorization architecture, the buffered
operation remains non-effective until the network Finality Sink
verifies its operation-specific execution capability.
If the capability is missing, invalid, revoked, expired, or
inconsistent with the actual transmitted request, the network
Finality Sink refuses transmission.
The outcome demonstrates the difference between stopping further
model computation and preventing a particular downstream effect.
11.14.39. WF-14.39 — Illustrative Multi-Sink Workflow
An AI agent performs a workflow involving:
(a) retrieving permitted source information;
(b) generating a proposed database update;
(c) requesting a payment; and
(d) issuing an external notification.
The model-access gate authorizes the required computation.
The protected operation-classification component identifies separate
Candidate Acts for the governed consequential stages.
Das Expires 19 April 2027 [Page 591]
Internet-Draft Protected AI Execution Finality October 2026
The applicable Finality Sinks may comprise:
(a) network egress for the retrieval or outbound request;
(b) database-commit interface for the persistent update;
(c) payment execution interface for the transfer; and
(d) communication gateway for the notification.
Each consequential operation receives its own required protected
authorization.
A capability permitting the database update cannot independently
authorize the payment.
Likewise, successful payment authorization does not automatically
authorize transmission of unrelated protected data through the
notification gateway.
The workflow progresses according to its applicable operation-
specific authorization conditions.
11.14.40. WF-14.40 — Protected Capability Consumption and Replay
Prevention
Where the operation-specific capability is single-use or usage-
bounded, the downstream Finality Sink performs or coordinates the
required protected capability-consumption procedure.
A representative state record comprises:
capability_id;
candidate_act_digest;
source_inference_reference;
authorized_effect_class;
finality_sink_id;
remaining_uses;
state_version;
status.
Das Expires 19 April 2027 [Page 592]
Internet-Draft Protected AI Execution Finality October 2026
The protected consumption mechanism prevents incompatible concurrent
operations from independently consuming the same restricted
authorization.
A previously consumed single-use capability is rejected upon
unauthorized replay.
Where bounded repeated use is expressly permitted, the corresponding
scope, validity, and usage restrictions are enforced.
A computation-admission record or model-session identifier does not
substitute for the protected consumption state required for a
downstream operation.
11.14.41. WF-14.41 — Crash, Retry, and Recovery
The system distinguishes failures at the model-access boundary from
failures at the downstream effectuation boundary.
Failure before model admission: Further governed computation does not
begin without the required computation-admission authority.
Failure after model admission but before Candidate Act generation: No
downstream consequential operation is inferred merely from the
existence of the admission record.
Failure after Candidate Act generation but before protected evidence
commitment: The act remains non-effective and no valid corresponding
downstream capability is made available.
Failure after protected evidence commitment but before capability
delivery: The system consults the committed authorization and
capability state before recovery or reissuance.
Failure after downstream capability availability but before
effectuation: The Finality Sink verifies current protected
authorization and consumption state before any permitted
continuation.
Failure after possible remote effectuation: The system distinguishes
a confirmed completed operation from a failed or indeterminate
operation.
An operation having uncertain completion status is not automatically
replayed when unauthorized duplicate effectuation could result.
Das Expires 19 April 2027 [Page 593]
Internet-Draft Protected AI Execution Finality October 2026
Where available, remote idempotency records, authenticated completion
receipts, transaction-status queries, or protected receiving-side
state may support reconciliation.
The architecture does not assert unconditional exactly-once
completion across arbitrary remote systems.
11.14.42. WF-14.42 — Alternative Structural Implementations
The dual-boundary architecture may be implemented through several
non-limiting arrangements.
Single-node implementation: A protected server performs model-access
authorization and downstream act-finality verification through
distinguishable functions within the same node.
Separated-server implementation: A model-access gateway controls
inference while another protected authority and Finality Sink govern
external operations.
Confidential-computing implementation: The computation environment or
protected authority operates inside a confidential VM, secure
enclave, or equivalent protected domain, with separate enforcement at
the downstream effectuation interface.
Hardware-assisted implementation: A SmartNIC, DPU, or protected
network controller may govern a designated model or network access
path, while a separate payment, storage, tool, or actuator Finality
Sink controls the corresponding downstream consequential operation.
Receiving-side implementation: A remote gateway or protected service
verifies operation-specific authority before completing the governed
receiving-side operation.
Streaming implementation: A model-output controller buffers partial
outputs until their corresponding bounded consequential acts satisfy
the required finality checks.
Multi-agent implementation: A parent agent or sub-agent may generate
a Candidate Act, but the delegated task or computation context does
not independently authorize the consequential operation.
Multi-sink implementation: A complex workflow uses different Finality
Sinks for network, storage, financial, tool-execution, or physical
effects.
The selected implementation determines the actual trust boundary,
bypass resistance, revocation latency, and failure assumptions.
Das Expires 19 April 2027 [Page 594]
Internet-Draft Protected AI Execution Finality October 2026
A hardware model-access gate does not automatically provide
downstream effectuation guarantees for interfaces it does not
control.
11.14.43. WF-14.43 — Failure and Fail-Closed Conditions
The system refuses the governed operation when a mandatory condition
is absent, invalid, expired, revoked, replayed, inconsistent, or
unverifiable.
Non-limiting conditions include:
(a) missing model-computation admission authority;
(b) invalid workload identity;
(c) unauthorized requested model;
(d) invalid approved computation context;
(e) revoked model-access authorization;
(f) missing Candidate Act Descriptor;
(g) failed downstream operation classification;
(h) unavailable required Non-Effective State holding mechanism;
(i) invalid inference-to-act context where required;
(j) invalid operation-specific Authority Object;
(k) unauthorized destination or recipient;
(l) prohibited operation type;
(m) failed protected-state transition;
(n) failed required validation-evidence commitment;
(o) missing operation-specific execution capability;
(p) invalid capability authentication;
(q) policy epoch mismatch;
(r) invalid revocation state;
Das Expires 19 April 2027 [Page 595]
Internet-Draft Protected AI Execution Finality October 2026
(s) expired nonce;
(t) replayed or consumed capability;
(u) unauthorized Finality Sink substitution;
(v) mismatch between actual remote operation and authorized
descriptor;
(w) incomplete streaming operation where complete parameters are
mandatory;
(x) unavailable required receiving-side state;
(y) failed downstream capability verification; or
(z) failure of the mandatory enforcement path.
The corresponding Candidate Act remains non-effective, denied,
quarantined, or subject to a separately authorized recovery or
escalation process.
An interruption of model inference does not create authority to
release buffered downstream operations.
11.14.44. WF-14.44 — PHOSITA Verification and Negative Tests
A person having ordinary skill in AI model-serving systems, agent
orchestration, distributed authorization, cryptography, network
security, transaction processing, or protected computing may test the
architecture through the following cases.
Test 1 — Authorized model request: Present a computation request
satisfying the required model, workload, context, and policy
conditions. The model-access gate admits the computation.
Test 2 — Unauthorized model request: Request a prohibited model. The
model-access gate refuses computation.
Test 3 — Downstream missing capability: Successfully admit the model,
then submit a consequential operation without an operation-specific
capability. The downstream Finality Sink refuses the operation.
Test 4 — Inference-to-act mismatch: Associate a Candidate Act with an
incompatible computation-admission record where that binding is
mandatory. Protected authorization fails.
Das Expires 19 April 2027 [Page 596]
Internet-Draft Protected AI Execution Finality October 2026
Test 5 — Destination substitution: Authorize one network recipient
and present a different destination at the Finality Sink.
Verification fails.
Test 6 — Operation substitution: Authorize a read operation and
attempt a write operation using the same capability. Required
operation correspondence fails.
Test 7 — Model interruption with buffered act: Interrupt further
model inference after an external operation has been buffered.
Confirm that the buffered act remains subject to downstream
capability verification.
Test 8 — Streaming partial command: Present an incomplete command
that lacks required effectuation parameters. The operation is
withheld.
Test 9 — Completed streaming command: Assemble an authorized bounded
Candidate Act and verify its corresponding capability before
effectuation.
Test 10 — Streaming payload mutation: Modify a required command or
payload field after authorization. The Finality Sink rejects the
mismatch.
Test 11 — Multiple Finality Sinks: Authorize a network transmission
and attempt to reuse the capability for a database commit. The
database Finality Sink refuses unauthorized reuse.
Test 12 — Remote recipient mismatch: Present the capability to a
remote executor operating on a different recipient. Remote
verification fails.
Test 13 — Remote protected-state mismatch: Present a valid-looking
capability referencing an incompatible protected-state version.
Effectuation is refused.
Test 14 — Model-access revocation: Revoke the model-access grant.
Further governed inference is blocked, while existing Candidate Acts
remain governed by their downstream authorization conditions.
Test 15 — Policy-epoch mismatch: Present a downstream capability
inconsistent with the current mandatory policy epoch. The Finality
Sink refuses it.
Test 16 — Capability replay: Reuse a consumed single-use operation
capability. Protected usage verification rejects the attempt.
Das Expires 19 April 2027 [Page 597]
Internet-Draft Protected AI Execution Finality October 2026
Test 17 — Concurrent operation attempts: Submit two incompatible
effects using the same restricted authorization state. The protected
mechanism prevents unauthorized double consumption.
Test 18 — Wrong Finality Sink: Present a capability bound to one sink
at a different sink. Required sink binding fails.
Test 19 — Receiving-side descriptor reconstruction: Submit a remote
operation with authorized parameters. Verify that the receiving
service independently reconstructs and checks the corresponding
operation descriptor.
Test 20 — Model gate bypass: Attempt access to the governed model
service through an alternate route. The admission requirement
remains enforced within the specified path coverage.
Test 21 — Downstream path bypass: Attempt to effectuate the
consequential operation through an alternative execution interface.
The required Finality Sink cannot be bypassed under the specified
threat model.
Test 22 — Upstream allow-only design: Provide a successful model-
access authorization but no separate valid downstream execution
capability. The consequential operation remains blocked.
Test 23 — Quarantine after completed effect: Trigger model quarantine
after a remote operation has already completed. Confirm that the
system does not falsely report the previous effect as prevented.
Test 24 — Crash before evidence commitment: Interrupt the protected
downstream transaction before required commitment. No valid
operation-specific capability becomes available.
Test 25 — Crash after possible remote execution: Interrupt
communication after the receiving service may have completed the
operation. Recovery distinguishes indeterminate status from
confirmed failure.
Test 26 — Multi-hop workflow: Authorize an upstream network effect
and attempt an unrelated downstream commit without its required
capability. The downstream Finality Sink refuses it.
Test 27 — Single-node dual authorization: Implement both
authorization functions within one protected node and verify that
model-admission authorization does not bypass downstream effectuation
checks.
Das Expires 19 April 2027 [Page 598]
Internet-Draft Protected AI Execution Finality October 2026
Test 28 — Distributed dual authorization: Place the model-access gate
and receiving-side Finality Sink on separate nodes. Verify that each
independently enforces its required authority.
Test 29 — Protected context substitution: Change the computation-
admission reference attached to a Candidate Act. Required
authenticated context binding fails.
Test 30 — Failure of model-path controls: Disable the model-access
gate after an already generated Candidate Act exists. Verify that
the downstream Finality Sink continues to enforce the applicable
protected execution-finality requirements independently of model-path
availability.
The tests may employ simulated inference gateways, AI-agent runtimes,
controllable tool executors, model-output stream generators,
protected authorization services, mock payment systems, test
databases, receiving-side gateways, programmable Finality Sinks, and
fault-injection mechanisms.
The observed guarantees depend upon the actual implemented
enforcement paths and protected-state mechanisms.
11.14.45. WF-14.45 — Claim-Specific Technical Support
Enforcement Point 68 — Model-Path and Effectuation-Path Dual
Authorization System
The workflow describes:
(a) ME-1401 receiving governed model-computation requests;
(b) MG-1402 verifying computation-admission authorization;
(c) AE-1405 generating consequential operations from admitted
computation;
(d) OC-1406 and HQ-1407 classifying and holding resulting Candidate
Acts;
(e) PED-1409 validating the concrete operation descriptor, authority,
protected policy state, and intended effectuation boundary;
(f) EV-1411 committing operation-specific validation evidence before,
or atomically with, capability availability;
(g) CR-1412 releasing the required scoped operation-specific
capability;
Das Expires 19 April 2027 [Page 599]
Internet-Draft Protected AI Execution Finality October 2026
(h) FS-1416 independently verifying the capability before
effectuation;
(i) separation between model-access authorization and downstream
execution authorization; and
(j) preservation of downstream authorization requirements after
model-access interruption or revocation.
Enforcement Point 69 — Inference-to-Act Context Binding
WF-14.8, WF-14.9, and WF-14.13 provide a protected computation-
admission record comprising model identity, workload identity,
approved execution context, policy epoch, and authorization-state
identifier.
The record is cryptographically associated with the downstream
Candidate Act without replacing operation-specific execution
authority.
Enforcement Point 70 — Streaming Output and Partial-Action Control
WF-14.28 through WF-14.31 describe streaming outputs, tool-call
fragments, partial command representations, completed or bounded
Candidate Act formation, and withholding of consequential fragments
until the required downstream capability verifies.
Interruption of future inference does not automatically authorize
release of previously buffered operations.
Enforcement Point 71 — Multi-Sink Effectuation Classification
WF-14.32 and WF-14.33 classify consequential operations according to
their applicable effectuation boundaries.
A capability for one operation or Finality Sink does not
independently authorize another operation or sink.
Enforcement Point 72 — Remote Effectuation Verification
WF-14.34 through WF-14.36 describe receiving-side reconstruction or
verification of the actual Candidate Act and verification against the
operation-specific capability and required protected validation-state
commitment.
Unauthorized changes to recipient, destination, operation type,
protected-state version, or execution scope cause refusal where those
fields are mandatory.
Das Expires 19 April 2027 [Page 600]
Internet-Draft Protected AI Execution Finality October 2026
11.14.46. WF-14.46 — Technical Effect
The disclosed workflow establishes two protected authorization
relationships.
The first governs admission of a proposed model computation.
The second governs the transition of a model-derived Candidate Act
into an externally effective operation.
The operative protected sequence includes:
(a) generation of a proposed inference request;
(b) verification of computation-admission authority at the model-
access gate;
(c) creation of an authenticated computation-admission context;
(d) controlled model computation;
(e) classification of consequential operations derived from the
computation;
(f) maintenance of each governed Candidate Act in a Non-Effective
State;
(g) construction of an operation-specific Candidate Act Descriptor;
(h) protected validation of actual operation, execution authority,
policy state, scope, and designated Finality Sink;
(i) required protected-state handling;
(j) protected validation-evidence commitment;
(k) release or availability of the operation-specific execution
capability;
(l) independent verification at the downstream effectuation boundary;
(m) capability-consumption and replay-prevention handling where
required; and
(n) controlled external effectuation or fail-closed withholding.
Das Expires 19 April 2027 [Page 601]
Internet-Draft Protected AI Execution Finality October 2026
The architecture prevents authorization to access an AI model from
being treated as unrestricted authority to carry out actions derived
from that model.
The streaming embodiment prevents consequential fragments or buffered
operations from escaping the required downstream authorization merely
because inference was interrupted or a partial output was generated.
The multi-sink embodiment preserves separate authorization for
separate consequential boundaries.
The remote verification embodiment requires the receiving Finality
Sink to verify the concrete operation presented for effectuation
instead of merely relying upon upstream approval.
A model-access choke point may prevent further governed inference,
but it is not presumed to control every downstream network, database,
payment, deployment, or physical-actuation interface.
The stronger protected effectuation guarantee arises from the actual
downstream capability-dependent Finality Sink verification.
Computation is not authority to act.
Authorization to access a model is not authorization to execute its
output.
Stopping future inference is not equivalent to preventing an already
prepared external operation.
An upstream authorization does not replace downstream execution-
finality verification.
11.15. WF-15 — Protected Cross-Domain AI-Fabric Transfer Finality,
GPU/TPU/NPU Accelerator Isolation, Hardware-Latched DMA and
Interconnect Admission, Continuous Tensor-Stream Authorization,
Hardware Freshness, and Line-Rate Capability Verification
11.15.1. WF-15.1 — Technical Purpose
This embodiment describes a computer-implemented, hardware-assisted
protected execution-finality architecture for governing the transfer,
replication, routing, switching, copying, export, admission, or
delivery of artificial-intelligence computation state between
compute, accelerator, memory, network-fabric, or other protected
execution domains.
Das Expires 19 April 2027 [Page 602]
Internet-Draft Protected AI Execution Finality October 2026
The technical objective is to prevent an accelerator or associated
computational workload from converting its ability to generate or
possess computation data into unrestricted authority to transfer that
data across a governed fabric-finality boundary.
The protected computation data may comprise:
(a) model parameters;
(b) tensors;
(c) key-value cache data;
(d) gradients;
(e) activations;
(f) embeddings;
(g) inference context;
(h) checkpoint state;
(i) model intermediate results;
(j) accelerator-resident memory content;
(k) agent-generated tool or control representations; or
(l) other governed artificial-intelligence computation data.
A proposed cross-domain transfer is classified as a Candidate Fabric
Transfer Act.
The Candidate Fabric Transfer Act remains in a Non-Effective State
until the applicable Protected Enforcement Domain (PED/CIED)
validates the required Cross-Domain Fabric Authorization Object,
performs applicable protected authorization-state operations,
generates or commits protected transfer-validation evidence, and
releases or makes available a scoped Fabric Transfer Capability.
A hardware-associated fabric Finality Sink independently verifies the
capability before enabling the governed transfer.
The transfer cannot cross its controlled effectuation boundary when
the required capability is absent, invalid, expired, revoked,
replayed, consumed, or inconsistent with the authorized operation.
Das Expires 19 April 2027 [Page 603]
Internet-Draft Protected AI Execution Finality October 2026
The architecture separates:
(a) accelerator computation;
(b) possession of computation data;
(c) preparation of a cross-domain transfer;
(d) protected authorization of the specific transfer;
(e) release of bounded transfer authority; and
(f) actual hardware-associated admission, forwarding, switching,
copying, or delivery.
Computation is not authority to transfer.
11.15.2. WF-15.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises:
AC-1501 — Source Accelerator or Compute Domain
A GPU, TPU, NPU, CPU, FPGA, AI accelerator, accelerator partition,
compute node, confidential workload, or equivalent component
producing or holding governed computation data.
DC-1502 — Destination Compute or Memory Domain
A destination accelerator, memory region, compute node, network
domain, protected workload, processing partition, or other receiving
domain.
FI-1503 — Fabric Transfer Interception Component
A NIC, SmartNIC, DPU, accelerator interconnect controller, fabric
switch, memory-fabric gateway, optical interconnect controller,
accelerator-management component, or equivalent mechanism configured
to intercept or prevent an unverified transfer.
HQ-1504 — Non-Effective Transfer Holding Mechanism
A controlled buffer, DMA descriptor queue, fabric admission queue,
protected memory region, sealed output store, inactive transfer
descriptor, or other mechanism maintaining a proposed transfer before
effectuation.
DF-1505 — Candidate Fabric Transfer Descriptor Component
Das Expires 19 April 2027 [Page 604]
Internet-Draft Protected AI Execution Finality October 2026
A component configured to construct or verify a machine-readable
descriptor of the proposed transfer and its effectuation-relevant
context.
PED-1506 — Protected Enforcement Domain
A protected component configured to authenticate the applicable
Cross-Domain Fabric Authorization Object, validate required authority
predicates, perform or verify protected-state operations, commit
required validation evidence, and control Fabric Transfer Capability
availability.
AS-1507 — Cross-Domain Fabric Authority Store
An authenticated or protected mechanism maintaining permitted source
and destination domains, data classifications, workload
relationships, routes, transfer limits, jurisdiction conditions,
policy state, and other authorized fabric-transfer conditions.
PS-1508 — Protected Fabric Authorization-State Store
A protected mechanism maintaining authorization grants, nonce state,
revocation state, fabric epochs, hardware freshness, transfer quotas,
capability usage, validation commitments, and required fabric-state
references.
EV-1509 — Fabric Validation-Evidence Component
A mechanism generating or committing a Fabric Transfer LAVR, ZK-LAVR,
authenticated validation record, sealed receipt, or equivalent
protected evidence.
CR-1510 — Fabric Transfer Capability Mechanism
A protected component configured to generate, register, derive,
release, or activate a bounded Fabric Transfer Capability.
HL-1511 — Hardware Finality Latch
A hardware-controlled enabling or admission mechanism preventing the
governed transfer from entering or crossing the relevant fabric
interface until required authorization verification succeeds.
FS-1512 — Fabric Finality Sink
Das Expires 19 April 2027 [Page 605]
Internet-Draft Protected AI Execution Finality October 2026
A hardware-associated admission queue, fabric lane, switching
pipeline, DMA controller, accelerator memory-access controller,
network-forwarding interface, optical controller, or cross-domain
delivery boundary that verifies the required capability before
effectuation.
HF-1513 — Hardware Freshness Component
A protected counter, fabric sequence number, trusted time source,
switch-state generation, boot epoch, or equivalent hardware-protected
state mechanism.
RM-1514 — Continuous Transfer and Route Monitor
A mechanism configured to observe or validate transfer-unit
progression, authorized workload graph, transfer size, destination,
and route state.
FV-1515 — Fast-Path Capability Verification Component
A bounded-time local verifier that checks an authenticated fabric
admission entry, protected capability lookup, sequence number, route
grant, or equivalent transfer-enablement state.
OS-1516 — Fabric Transfer Outcome-State Component
A protected mechanism maintaining pending, reserved, admitted,
completed, denied, revoked, expired, or indeterminate transfer
status.
The described functions may be integrated into one protected
accelerator controller or distributed across multiple accelerator,
memory, fabric, network, or hardware security components.
Functional distinction does not necessarily require a physically
separate component for every identified role.
11.15.3. WF-15.3 — Establishment of the Accelerator and Fabric Trust
Boundaries
The system establishes one or more protected boundaries between
computation domains capable of generating or holding protected data
and the interfaces capable of transferring that data to another
domain.
A governed transfer boundary may comprise:
(a) accelerator memory to host memory;
Das Expires 19 April 2027 [Page 606]
Internet-Draft Protected AI Execution Finality October 2026
(b) one accelerator to another accelerator;
(c) accelerator memory to an external network interface;
(d) device-local memory to shared fabric memory;
(e) a PCIe or CXL transfer interface;
(f) an accelerator-to-interconnect boundary;
(g) a protected tensor store to a remote computation node;
(h) a DMA or RDMA transfer interface;
(i) a switch ingress or egress pipeline;
(j) an optical interconnect interface; or
(k) another consequential cross-domain delivery boundary.
The source compute domain may possess and operate on protected data
without possessing authority to transfer it through the governed
boundary.
The system identifies all effectuation paths relevant to the
specified transfer class.
Where a mandatory non-bypassable property is required, the source
workload cannot circumvent the protected interface using an
alternative device, queue, DMA mapping, fabric route, host-copy
operation, or direct network interface capable of producing the same
governed effect.
Actual path coverage must be enforced through suitable hardware,
firmware, hypervisor, memory-protection, IOMMU, switch-control, or
other mechanisms appropriate to the implementation.
11.15.4. WF-15.4 — Hardware-Assisted Enforcement Configuration
In an implementation using accelerator and fabric hardware, the
system configures the selected transfer interfaces so that the
requesting workload cannot independently enable protected cross-
domain movement.
An illustrative configuration may comprise:
(a) restricted DMA mappings;
Das Expires 19 April 2027 [Page 607]
Internet-Draft Protected AI Execution Finality October 2026
(b) protected accelerator memory regions;
(c) fabric-switch admission rules;
(d) protected queue-pair creation;
(e) controlled memory-window permissions;
(f) device-side transfer authorization;
(g) protected interconnect route entries;
(h) hardware-controlled output buffers;
(i) protected device security registers; or
(j) a hardware transfer-enable latch.
The actual implementation determines whether an operation is blocked
at submission, queue admission, descriptor consumption, memory
mapping, routing, switching, or data delivery.
The presence of a hardware component does not independently establish
non-bypassability.
The component must control the relevant transfer path and enforce the
required authorization relationship.
11.15.5. WF-15.5 — Definition of the Governed Transfer Effect
For this embodiment, a Candidate Fabric Transfer Act becomes
effective when the specified protected computation data crosses the
governed fabric-finality boundary or acquires the corresponding
authorized delivery or access consequence.
The applicable effect may comprise:
(a) DMA copying into another memory protection domain;
(b) fabric switching to another accelerator;
(c) RDMA transfer to a remote compute node;
(d) release from protected accelerator memory;
(e) activation of an authorized memory mapping;
(f) forwarding through a protected fabric route;
Das Expires 19 April 2027 [Page 608]
Internet-Draft Protected AI Execution Finality October 2026
(g) replication of governed tensor state; or
(h) another defined transfer consequence.
An operation does not have to leave a physical server to become
externally effective.
A transfer from one protected GPU memory partition into a differently
authorized memory domain may constitute a governed consequential
effect.
The authorization boundary is selected according to the actual
security and data-governance requirement.
11.15.6. WF-15.6 — Generation of the Candidate Fabric Transfer Act
AC-1501 executes an AI computation, training operation, inference
process, or other permitted workload.
The workload proposes transfer of protected computation data to DC-
1502.
An illustrative request identifies:
transfer_id;
source_compute_domain;
destination_compute_domain;
source_memory_region;
destination_memory_region;
computation_data_class;
transfer_operation;
data_reference;
transfer_size;
fabric_route;
workload_identity;
policy_epoch.
Das Expires 19 April 2027 [Page 609]
Internet-Draft Protected AI Execution Finality October 2026
The proposed operation is classified as Candidate Fabric Transfer Act
CFTA-1517.
The classification does not imply that the transfer has been
authorized.
The transfer remains subject to protected validation and fabric
Finality Sink verification.
11.15.7. WF-15.7 — Interception and Non-Effective Transfer Staging
FI-1503 intercepts or controls CFTA-1517 before the governed transfer
occurs.
HQ-1504 maintains the proposed transfer in a Non-Effective State.
An illustrative pending transfer record comprises:
transfer_id;
source_domain_id;
destination_domain_id;
source_buffer_reference;
destination_buffer_reference;
transfer_operation;
transfer_size;
candidate_descriptor_reference;
policy_epoch;
fabric_sink_id;
status = NON_EFFECTIVE.
The source data may remain resident within accelerator memory.
Alternatively, the system may retain an inactive transfer descriptor,
blocked DMA command, disabled queue entry, or authenticated buffer
reference.
The arrangement prevents the transfer operation from becoming
effective while mandatory authorization conditions remain unresolved.
Das Expires 19 April 2027 [Page 610]
Internet-Draft Protected AI Execution Finality October 2026
Merely recording the transfer request in a queue is insufficient if
another accessible interface can perform the same protected transfer
without verification.
11.15.8. WF-15.8 — Candidate Fabric Transfer Act Descriptor Formation
DF-1505 constructs a descriptor representing the proposed transfer
and its effectuation-relevant context.
The descriptor identifies at least:
(a) source compute domain;
(b) destination compute domain;
(c) computation-data class;
(d) requested transfer operation; and
(e) applicable fabric-finality boundary.
The descriptor may also identify:
source_accelerator_measurement;
destination_accelerator_measurement;
workload_identity;
tenant_identity;
model_identity;
tensor_class;
memory_region;
transfer_size;
collective_operation_type;
fabric_route;
switch_identity;
jurisdiction;
approved_workload_graph_reference;
Das Expires 19 April 2027 [Page 611]
Internet-Draft Protected AI Execution Finality October 2026
runtime_transfer_envelope;
policy_epoch;
nonce;
expiry;
fabric_finality_sink_identity.
Only fields required by the corresponding Authority Object or
specified embodiment are mandatory.
The descriptor distinguishes the actual requested cross-domain
transfer from a general authorization to execute the source AI
workload.
11.15.9. WF-15.9 — Canonical Transfer Descriptor Encoding
In an illustrative cryptographic implementation, DF-1505 encodes the
descriptor deterministically.
A non-limiting expression is:
Dfabric = Canon_v(SRC, DST, DATA, OP, REGION, SIZE, ROUTE, CONTEXT,
EPOCH, F)
where:
Dfabric denotes the canonical fabric-transfer descriptor;
Canon_v denotes deterministic canonical encoding under version v;
SRC denotes the verified source domain;
DST denotes the destination domain;
DATA denotes the protected computation-data class or identity;
OP denotes the requested transfer operation;
REGION denotes the relevant protected memory region;
SIZE denotes the authorized transfer size or bound;
ROUTE denotes the required fabric route;
Das Expires 19 April 2027 [Page 612]
Internet-Draft Protected AI Execution Finality October 2026
CONTEXT denotes applicable workload, accelerator, tenant, and runtime
context;
EPOCH denotes protected authorization-state information; and
F denotes the designated fabric Finality Sink.
An illustrative commitment is:
hFabric = H("DAS-FABRIC-TRANSFER-v1" || Encode(Dfabric))
where H denotes a cryptographic hash function.
The selected encoder maintains unambiguous field interpretation and
preserves distinctions affecting authorization.
The protected authorizer and Finality Sink employ corresponding
interpretation rules.
The formula is a non-limiting implementation elaboration.
11.15.10. WF-15.10 — Acquisition of Cross-Domain Fabric Authority
PED-1506 obtains or resolves the applicable Cross-Domain Fabric
Authorization Object from AS-1507.
The Authority Object may identify:
(a) authorized source domains;
(b) authorized destination domains;
(c) permitted computation-data classifications;
(d) approved workload identities;
(e) permitted tenant relationships;
(f) approved workload or collective-operation graphs;
(g) permitted memory regions;
(h) transfer-size limits;
(i) permitted fabric routes;
(j) jurisdictional restrictions;
Das Expires 19 April 2027 [Page 613]
Internet-Draft Protected AI Execution Finality October 2026
(k) runtime transfer envelopes;
(l) authorized switch or interconnect classes;
(m) required hardware measurements;
(n) policy epochs;
(o) revocation and freshness requirements; and
(p) permitted fabric Finality Sinks.
The PED authenticates the Authority Object and verifies its
applicability to the proposed transfer.
The requesting AI workload cannot independently widen cross-domain
authority merely by selecting a different memory address, route,
queue, or transfer descriptor.
11.15.11. WF-15.11 — Source-Domain Authority Validation
PED-1506 verifies the authority associated with the source compute
domain.
The validation may require:
(a) authenticated source workload identity;
(b) permitted source accelerator;
(c) source security-domain identity;
(d) authorized tensor or memory region;
(e) approved model or workload class;
(f) required accelerator attestation;
(g) permitted source data classification; and
(h) applicable protected authorization state.
Where exact source accelerator measurement is required, the protected
mechanism verifies the authenticated measurement rather than relying
upon an untrusted software description.
Das Expires 19 April 2027 [Page 614]
Internet-Draft Protected AI Execution Finality October 2026
A workload permitted to compute on an accelerator does not
automatically acquire authority to export every tensor or memory
region held by that accelerator.
11.15.12. WF-15.12 — Destination-Domain Authority Validation
PED-1506 separately evaluates the proposed destination domain.
The validation may require:
(a) authenticated destination identity;
(b) permitted destination accelerator or memory controller;
(c) authorized receiving workload;
(d) permitted tenant;
(e) destination memory protection state;
(f) permitted data classification;
(g) destination jurisdiction;
(h) approved receiving model or computation class; and
(i) required attestation or protected-state predicates.
A valid source-domain authorization does not establish destination-
domain authorization merely because the source can address or connect
to the destination.
The transfer is refused when the actual destination does not satisfy
a mandatory receiving-domain predicate.
11.15.13. WF-15.13 — Computation-Data Classification
The protected system identifies the category or classification of
data proposed for transfer.
The classification may distinguish:
(a) model weights;
(b) model parameters;
(c) gradients;
Das Expires 19 April 2027 [Page 615]
Internet-Draft Protected AI Execution Finality October 2026
(d) activation tensors;
(e) key-value cache state;
(f) embeddings;
(g) intermediate inference results;
(h) checkpoint material;
(i) privileged model state;
(j) personal or regulated data;
(k) confidential enterprise data; and
(l) other protected computation information.
Where data classification forms part of mandatory authorization, the
PED verifies that the proposed data class is permitted for the
destination and operation.
A general permission to exchange model parameters does not
automatically authorize transmission of protected inference context
or confidential key-value cache data.
11.15.14. WF-15.14 — Approved Workload Graph and Transfer Envelope
Where required, the PED evaluates the proposed operation against an
approved workload graph or runtime transfer envelope.
The graph may identify:
(a) authorized participating accelerators;
(b) permitted compute nodes;
(c) approved dataflow edges;
(d) allowed collective-operation classes;
(e) permitted source-destination relationships;
(f) authorized tensor classes;
(g) expected transfer phases;
(h) maximum transfer size;
Das Expires 19 April 2027 [Page 616]
Internet-Draft Protected AI Execution Finality October 2026
(i) permitted fabric paths; and
(j) other bounded workflow relationships.
A runtime transfer envelope may define acceptable transfer units,
sizes, timing windows, destination groups, sequence rules, or data-
class restrictions.
The PED validates the proposed transfer under the applicable graph
and envelope conditions.
A transfer outside the authorized graph is not permitted merely
because it is technically routable through the fabric.
11.15.15. WF-15.15 — Fabric Route and Switch Validation
The protected system verifies the selected fabric route when route
identity is a mandatory authorization predicate.
The applicable route may comprise:
(a) a NIC or SmartNIC path;
(b) a DPU-controlled network segment;
(c) an accelerator interconnect;
(d) an NVLink-class or equivalent accelerator fabric;
(e) a PCIe or CXL path;
(f) an optical interconnect;
(g) a memory-fabric gateway;
(h) a switch pipeline; or
(i) another permitted transfer path.
The descriptor or Authority Object may identify exact routes,
permitted path classes, switch identities, route epochs, or approved
destination sets.
Where the actual selected route differs from the required authorized
route, the previous authorization does not automatically remain
valid.
Das Expires 19 April 2027 [Page 617]
Internet-Draft Protected AI Execution Finality October 2026
The Finality Sink verifies the route attributes available and
required at its controlled boundary.
The system does not presume visibility of intermediate hardware or
remote routing state that the implementation cannot authenticate.
11.15.16. WF-15.16 — Protected Fabric Authorization Predicate
PED-1506 evaluates the mandatory authorization predicates applicable
to CFTA-1517.
An illustrative conjunctive predicate is:
Vfabric = Psource AND Pdestination AND Pdata AND Pgraph AND Proute
AND Penvelope AND Pstate
where:
Vfabric denotes the protected transfer-authorization result;
Psource verifies source-domain authority;
Pdestination verifies destination-domain authority;
Pdata verifies computation-data classification;
Pgraph verifies the approved workload graph;
Proute verifies the authorized fabric route;
Penvelope verifies required transfer-size, phase, and runtime
conditions; and
Pstate verifies current policy, revocation, freshness, and protected
authorization state.
Where additional hardware measurements or jurisdiction conditions are
mandatory, they are included in the protected validation procedure.
Where threshold or approved alternative authorization conditions
apply, the PED evaluates them according to the applicable protected
policy.
Failure of any mandatory predicate prevents issuance or availability
of the corresponding Fabric Transfer Capability.
Das Expires 19 April 2027 [Page 618]
Internet-Draft Protected AI Execution Finality October 2026
11.15.17. WF-15.17 — Protected Fabric Authorization-State Handling
Following successful protected predicate validation, PED-1506
performs the required protected-state operations.
Such operations may include:
(a) verification of the current fabric policy epoch;
(b) verification of revocation state;
(c) reservation of a transfer grant;
(d) allocation of a bounded transfer allowance;
(e) consumption or registration of a nonce;
(f) registration of a permitted source-destination pair;
(g) advancement of a fabric sequence number;
(h) protected transfer quota handling;
(i) registration of a route grant;
(j) reservation of a capability identifier; or
(k) another required authorization-state transition.
Where a restricted grant is single-use, protected state prevents two
incompatible transfers from independently consuming the same
authorization.
Where the transfer is explicitly bounded across multiple units, the
protected system maintains the corresponding usage, sequence, or
transfer-window restrictions.
A failed mandatory state transition prevents successful capability
availability.
11.15.18. WF-15.18 — Fabric Transfer Validation Evidence
EV-1509 generates or commits the protected validation evidence
required for the transfer.
The evidence may comprise a Fabric Transfer LAVR, ZK-LAVR,
authenticated validation record, sealed state commitment, or
equivalent protected representation.
Das Expires 19 April 2027 [Page 619]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative record comprises:
receipt_id;
transfer_id;
candidate_fabric_descriptor_digest;
source_domain_id;
destination_domain_id;
authorized_data_class;
workload_graph_reference;
authorized_route_reference;
transfer_envelope_reference;
policy_epoch;
protected_state_transition;
nonce;
fabric_finality_sink_id;
decision;
protected_authentication.
Where required by the embodiment, validation evidence is committed
before, or atomically with, capability availability.
A conventional transfer-completion log generated after data delivery
does not substitute for mandatory pre-effectuation validation-
evidence commitment.
The receipt may remain inside protected storage or a protected fabric
state mechanism.
Immediate external-ledger publication is not necessary unless
separately required by the particular embodiment.
Das Expires 19 April 2027 [Page 620]
Internet-Draft Protected AI Execution Finality October 2026
11.15.19. WF-15.19 — Protected Fabric Finality Transaction
PED-1506 coordinates validation, protected-state handling, evidence
commitment, and capability availability.
An illustrative protected transaction is:
(Snext, Rfabric, Ready) = CommitFabricFinality(Dfabric, A, Scurrent,
F)
where:
Snext denotes successfully committed protected fabric-authorization
state;
Rfabric denotes the protected Fabric Transfer validation evidence;
Ready denotes the protected indication that the mandatory capability-
release prerequisites have succeeded;
Dfabric denotes the validated transfer descriptor;
A denotes the authenticated Cross-Domain Fabric Authorization Object;
Scurrent denotes prior protected authorization state; and
F denotes the designated fabric Finality Sink.
The capability-release mechanism does not treat an incomplete
mandatory transaction as successful authorization.
The implementation may employ protected transactional state, an HSM-
controlled state service, an authenticated fabric controller, secure
counters, or equivalent protected mechanisms.
Where several components participate, the required authorization
dependencies must be verifiably committed before the resulting
capability becomes usable.
11.15.20. WF-15.20 — Scoped Fabric Transfer Capability
Following successful protected authorization, CR-1510 makes available
a scoped Fabric Transfer Capability.
The capability may contain or securely reference:
capability_id;
Das Expires 19 April 2027 [Page 621]
Internet-Draft Protected AI Execution Finality October 2026
candidate_fabric_descriptor_digest;
source_domain_id;
destination_domain_id;
workload_identity;
data_class;
source_memory_region;
destination_memory_region;
permitted_transfer_operation;
transfer_size_limit;
approved_route;
workload_graph_reference;
policy_epoch;
revocation_epoch;
hardware_freshness_reference;
nonce;
expiry;
remaining_usage;
validation_evidence_digest;
fabric_finality_sink_id.
The capability may comprise:
(a) a cryptographically signed authorization artifact;
(b) a MAC-authenticated transfer permit;
(c) a protected capability-table entry;
(d) an authenticated DMA descriptor;
Das Expires 19 April 2027 [Page 622]
Internet-Draft Protected AI Execution Finality October 2026
(e) a protected queue-pair capability;
(f) a hardware forwarding grant;
(g) a sealed transfer handle; or
(h) an equivalent protected execution-enablement condition.
Possession of the capability representation alone does not
independently authorize transfer outside the required operation,
domain, route, protected-state, usage, and Finality Sink bindings.
11.15.21. WF-15.21 — Illustrative Cryptographic Capability
Representation
A non-limiting signature-based implementation may use:
Cfabric = Sign_skPED(Encode(hFabric, hR, SRC, DST, DATA, OP, ROUTE,
LIMIT, EPOCH, HF, NONCE, EXPIRY, F))
where:
Cfabric denotes the authenticated Fabric Transfer Capability;
Sign_skPED denotes signing under a PED-controlled private key;
hFabric denotes the authorized transfer-descriptor digest;
hR denotes the validation-evidence commitment digest;
SRC denotes the source compute-domain binding;
DST denotes the destination compute-domain binding;
DATA denotes the permitted computation-data class;
OP denotes the authorized transfer operation;
ROUTE denotes the permitted route;
LIMIT denotes transfer-size or usage restrictions;
EPOCH denotes the required policy epoch;
HF denotes the hardware-freshness binding;
NONCE denotes the capability freshness value;
Das Expires 19 April 2027 [Page 623]
Internet-Draft Protected AI Execution Finality October 2026
EXPIRY denotes the capability validity limit; and
F denotes the designated fabric Finality Sink.
The selected implementation may avoid asymmetric signature
verification on each transfer unit by using an authenticated
protected capability entry established through a higher-cost
authorization procedure.
The cryptographic representation is illustrative and does not impose
a mandatory algorithm or serialization format on all implementations.
11.15.22. WF-15.22 — Independent Verification at the Fabric Finality
Sink
FS-1512 obtains the actual transfer descriptor, protected transfer
entry, hardware context, or effectuation-relevant operation
information.
Before admitting the transfer, the Finality Sink verifies:
(a) capability authenticity;
(b) source-domain binding;
(c) destination-domain binding;
(d) data-class scope;
(e) permitted transfer operation;
(f) memory-region restrictions;
(g) transfer size or window;
(h) required fabric route;
(i) policy epoch;
(j) revocation conditions;
(k) nonce and expiry;
(l) required hardware freshness;
(m) protected validation-evidence reference;
(n) usage or consumption state; and
Das Expires 19 April 2027 [Page 624]
Internet-Draft Protected AI Execution Finality October 2026
(o) fabric Finality Sink identity.
The Finality Sink verifies the operation that is actually presented
rather than relying exclusively upon an earlier software assertion
that the transfer was permitted.
The governed transfer remains blocked when a mandatory verification
condition fails.
11.15.23. WF-15.23 — Fabric Finality Verification Predicate
An illustrative verification predicate is:
PermitFabric = Auth(C) AND Match(C,Dactual) AND
DomainsValid(C,SRC,DST) AND RouteValid(C,Ractual) AND StateValid(C,P)
AND FreshnessValid(C,H) AND SinkValid(C,F)
where:
PermitFabric denotes permission to perform the governed transfer;
C denotes the Fabric Transfer Capability;
Dactual denotes the actual fabric-transfer descriptor;
SRC and DST denote actual source and destination domains;
Ractual denotes the actual relevant transfer route;
P denotes the required protected authorization state;
H denotes applicable hardware-freshness state; and
F denotes the designated fabric Finality Sink.
Auth verifies capability authenticity.
Match verifies exact descriptor correspondence or expressly permitted
bounded-scope matching.
DomainsValid verifies the authorized source and destination.
RouteValid verifies the applicable route restrictions.
StateValid verifies required policy, revocation, evidence, and usage
state.
FreshnessValid verifies hardware freshness when mandatory.
Das Expires 19 April 2027 [Page 625]
Internet-Draft Protected AI Execution Finality October 2026
SinkValid verifies the authorized Finality Sink.
All mandatory conditions must succeed before the governed transfer is
admitted.
11.15.24. WF-15.24 — Hardware-Latched Transfer Admission
in the implementation described by enforcement point 50, HL-1511
maintains the governed transfer interface in a hardware-disabled,
non-admitting, or otherwise non-effective state until the required
Fabric Transfer Capability verifies.
The controlled interface may comprise:
(a) a fabric lane;
(b) a switch admission entry;
(c) a DMA queue;
(d) an optical path;
(e) a memory-access interface;
(f) an accelerator transfer interface;
(g) a protected queue pair; or
(h) a hardware-controlled forwarding entry.
In one implementation, the transfer request may be staged in an
inactive DMA descriptor.
The hardware controller prevents the descriptor from becoming
eligible for execution until the authenticated transfer capability is
verified.
In another implementation, the fabric switch does not admit the
relevant route or forwarding entry until protected capability
verification succeeds.
The hardware latch permits only the specified bounded transfer.
A software allow decision that the hardware controller is free to
ignore or bypass does not satisfy the specified hardware-latched
effectuation requirement.
Das Expires 19 April 2027 [Page 626]
Internet-Draft Protected AI Execution Finality October 2026
11.15.25. WF-15.25 — Hardware-Latch Activation Sequence
A non-limiting hardware-latched transfer sequence comprises:
First, the source accelerator generates or prepares protected
computation data.
Second, a transfer request is submitted to the fabric interception
component.
Third, the proposed transfer is retained in a Non-Effective State.
Fourth, the Candidate Fabric Transfer Act Descriptor is formed.
Fifth, the PED authenticates the Cross-Domain Fabric Authorization
Object.
Sixth, the PED validates the mandatory source, destination, data-
class, workload-graph, route, transfer-envelope, policy, and
freshness predicates.
Seventh, required protected-state operations and Fabric Transfer
validation-evidence commitment are completed.
Eighth, the PED releases or activates the bounded Fabric Transfer
Capability.
Ninth, the hardware-associated Finality Sink verifies the capability
against the actual transfer.
Tenth, the hardware latch enables the authorized admission, routing,
copying, switching, or delivery operation.
Eleventh, the hardware or associated protected controller enforces
the applicable size, route, usage, and freshness restrictions.
Twelfth, the transfer capability is consumed, advanced, retired, or
maintained within its permitted bounded-use state according to the
authorization.
If required verification fails at the hardware Finality Sink, the
controlled transfer interface remains disabled or non-admitting for
the rejected operation.
11.15.26. WF-15.26 — Continuous Tensor and Memory-Transfer Validation
in the implementation described by enforcement point 51, a governed
transfer may comprise a sequence of transfer units.
Das Expires 19 April 2027 [Page 627]
Internet-Draft Protected AI Execution Finality October 2026
A transfer unit may be:
(a) a packet;
(b) a DMA block;
(c) a tensor slice;
(d) a memory page;
(e) a collective-operation phase;
(f) a transfer window;
(g) an accelerator communication chunk; or
(h) another bounded data-transfer unit.
The system may associate a protected validation receipt, rolling
Fabric Transfer Capability, or corresponding authenticated
authorization state with each required unit or window.
An earlier authorized unit does not automatically permit later units
outside the expressly authorized transfer scope.
The system enforces the granularity required by the applicable
embodiment.
Per-byte verification is not mandatory where the claim and protected
authority permit bounded transfer units and the corresponding
hardware enforces their limits.
11.15.27. WF-15.27 — Rolling Transfer Authorization State
In one implementation, the system maintains a rolling transfer-state
record.
A non-limiting record comprises:
transfer_id;
current_window;
authorized_route;
source_domain_id;
destination_domain_id;
Das Expires 19 April 2027 [Page 628]
Internet-Draft Protected AI Execution Finality October 2026
authorized_data_class;
maximum_transfer_size;
remaining_transfer_allowance;
last_sequence_number;
policy_epoch;
hardware_freshness_reference;
capability_id;
validation_evidence_reference;
status.
A subsequent transfer unit is admitted only when its required
authorization state remains valid.
An illustrative state progression is:
WINDOW_PENDING → WINDOW_AUTHORIZED → WINDOW_ADMITTED →
WINDOW_CONSUMED.
Where a bounded authorization supports several units, the protected
system decrements or advances the corresponding usage allowance.
An unauthorized window cannot independently consume or inherit the
authority of another window.
11.15.28. WF-15.28 — Continuous Transfer Monitoring and Drift Detection
RM-1514 evaluates required transfer conditions during an ongoing
fabric operation.
Such conditions may include:
(a) authorized route continuity;
(b) permitted destination;
(c) transfer-size constraints;
(d) expected tensor or data class;
(e) approved workload graph;
Das Expires 19 April 2027 [Page 629]
Internet-Draft Protected AI Execution Finality October 2026
(f) collective-operation phase;
(g) policy epoch;
(h) hardware sequence state;
(i) revocation state; or
(j) other applicable transfer-envelope predicates.
If a mandatory route, destination, size, graph, or protected-state
condition becomes invalid, the system withholds subsequent transfer
authorization or the Finality Sink rejects the affected transfer
unit.
The enforcement mechanism does not retroactively prevent transfer
units already delivered.
Its prevention guarantee applies to the subsequent units whose
admission remains under the applicable protected finality control.
11.15.29. WF-15.29 — Transfer-Size and Workload-Graph Anomaly Handling
In a continuous-transfer embodiment, the authorized workload graph
may specify permitted communication relationships and expected data
movement.
For example, a training collective operation may permit defined
exchanges among an approved set of accelerators.
The Candidate Fabric Transfer Act Descriptor identifies the required
operation class, transfer participants, data class, and bounded
transfer size.
If a workload attempts to:
(a) send protected data to an unauthorized accelerator;
(b) exceed a mandatory transfer-size limit;
(c) perform an unapproved collective operation;
(d) use an unauthorized memory region;
(e) change the permitted destination; or
(f) select a prohibited fabric route,
Das Expires 19 April 2027 [Page 630]
Internet-Draft Protected AI Execution Finality October 2026
the corresponding protected predicate fails.
The system withholds the required capability or denies admission of
the affected transfer unit.
An anomaly detector's observation alone does not establish prevention
if the hardware has already admitted the transfer.
The applicable security guarantee depends upon the finality check
being enforced before the controlled transfer unit becomes effective.
11.15.30. WF-15.30 — Hardware-Freshness Binding
in the implementation described by enforcement point 52, the Fabric
Transfer Capability is bound to a hardware-freshness value.
The freshness value may derive from:
(a) an accelerator counter;
(b) a fabric sequence number;
(c) secure switch state;
(d) a trusted clock;
(e) a secure monotonic counter;
(f) a boot epoch; or
(g) protected device state.
An illustrative freshness record comprises:
device_id;
boot_epoch;
fabric_epoch;
secure_counter;
sequence_number;
policy_epoch;
freshness_generation.
Das Expires 19 April 2027 [Page 631]
Internet-Draft Protected AI Execution Finality October 2026
The protected authorization mechanism associates the required
hardware-freshness state with the issued capability.
FS-1512 verifies the corresponding required freshness condition
before admitting the transfer.
A capability valid under a previous hardware generation does not
automatically authorize transfer under a different or rolled-back
state.
11.15.31. WF-15.31 — Hardware-Freshness Verification Procedure
In an illustrative implementation, the protected system performs the
following procedure.
First, HF-1513 provides an authenticated or hardware-protected
freshness reference.
Second, PED-1506 associates the reference with the Candidate Fabric
Transfer Act and applicable protected state.
Third, the resulting Fabric Transfer Capability incorporates or
securely references the required freshness condition.
Fourth, FS-1512 obtains the current freshness state from the
designated trusted hardware or protected state source.
Fifth, the Finality Sink compares the required capability freshness
against the applicable current state.
Sixth, the hardware interface admits the transfer only if the
freshness predicate succeeds together with the other mandatory
capability checks.
An illustrative predicate is:
FreshnessValid = EpochMatch AND CounterValid AND SequenceValid AND
NotRevoked
where each term applies only when required by the particular
embodiment.
A counter rollback, boot-epoch mismatch, replayed transfer sequence,
or invalid protected generation causes the applicable freshness
predicate to fail.
Das Expires 19 April 2027 [Page 632]
Internet-Draft Protected AI Execution Finality October 2026
11.15.32. WF-15.32 — Prevention of Replay Across Device Reset
A hardware reset or restart may change the state of an accelerator,
switch, NIC, DPU, or memory controller.
A previously valid capability must not become usable outside its
permitted state merely because volatile registers or queues were
restored.
In an implementation requiring rollback resistance, the protected
system binds capability validity to an authenticated boot epoch,
monotonic counter, or other persistent protected freshness mechanism.
After reset, the Finality Sink verifies that the presented capability
corresponds to the current authorized generation.
Capabilities referring to an incompatible earlier generation are
rejected.
Where persistent protected state cannot be established, the system
does not assume that replay resistance remains intact solely because
a capability contains a timestamp or software-generated nonce.
11.15.33. WF-15.33 — Cold-Path Authority Validation
in the implementation described by enforcement point 53, the
protected system separates comparatively higher-cost authority
validation from latency-sensitive transfer admission.
The cold path may perform:
(a) Authority Object authentication;
(b) source and destination attestation;
(c) workload-graph evaluation;
(d) data-classification validation;
(e) jurisdiction or tenant-policy evaluation;
(f) protected revocation-state validation;
(g) higher-cost cryptographic verification;
(h) protected transfer-state reservation;
(i) validation-evidence commitment; and
Das Expires 19 April 2027 [Page 633]
Internet-Draft Protected AI Execution Finality October 2026
(j) scoped Fabric Transfer Capability issuance.
The cold path may be implemented in a PED, CIED, secure control
processor, protected DPU service, HSM, or authenticated remote
authority.
Its result is not an unrestricted authorization for arbitrary future
transfers.
The permitted scope, route, usage, freshness, and Finality Sink
conditions remain bounded and enforceable at the fast path.
11.15.34. WF-15.34 — Bounded-Time Local Fabric Verification
The fast path comprises the hardware-associated Finality Sink or
local protected fabric enforcement interface.
The fast path may verify a compact authenticated admission record
using:
(a) a protected hardware lookup entry;
(b) a sequence counter;
(c) a short-lived authentication tag;
(d) a bounded route grant;
(e) an authenticated DMA descriptor;
(f) a queue-pair capability;
(g) a hardware transfer-enable entry; or
(h) an equivalent local transfer-admission record.
The local verifier determines whether the actual requested transfer
remains within the scope and state established through the protected
cold-path authorization.
The implementation may avoid performing expensive policy evaluation
for each packet or tensor slice where a properly bounded capability
is sufficient.
However, the local capability verification remains mandatory before
the governed transfer unit is admitted.
Das Expires 19 April 2027 [Page 634]
Internet-Draft Protected AI Execution Finality October 2026
The actual bounded-time and line-rate performance characteristics
depend upon the implemented hardware and workload.
11.15.35. WF-15.35 — Local Capability-Table Implementation
In one illustrative implementation, the PED installs an authenticated
transfer-admission entry into a protected hardware table.
An entry may comprise:
capability_id;
source_domain_id;
destination_domain_id;
permitted_queue_id;
authorized_data_class;
memory_region_scope;
route_id;
maximum_transfer_bytes;
remaining_transfer_bytes;
valid_policy_epoch;
valid_hardware_epoch;
next_sequence_number;
expiry;
receipt_commitment_reference;
status.
The fabric Finality Sink obtains the relevant entry and verifies the
actual transfer against its required fields.
If verification succeeds, the hardware admits only the bounded
transfer specified by the entry.
A mismatch in the destination, queue, route, size, freshness, or
required state causes the transfer to be refused.
Das Expires 19 April 2027 [Page 635]
Internet-Draft Protected AI Execution Finality October 2026
The protected table cannot be modified unilaterally by the requesting
AI workload under the applicable threat model.
11.15.36. WF-15.36 — Time-of-Check and Time-of-Use Protection
The architecture maintains correspondence between the transfer that
was authorized and the transfer actually presented for fabric
effectuation.
Potential substitutions include:
(a) changing the destination accelerator;
(b) modifying the source memory region;
(c) replacing a DMA descriptor;
(d) changing transfer size;
(e) altering the tensor or data class;
(f) modifying the route;
(g) substituting a queue pair;
(h) changing the workload identity;
(i) replaying an earlier fabric sequence; or
(j) using a capability under incompatible protected state.
Where exact transfer binding is required, the Finality Sink verifies
the actual fields against the authorized descriptor commitment.
Where bounded variation is permitted, the interface verifies the
specified bounds.
The system does not rely solely upon an upstream assertion that a DMA
command was previously approved.
11.15.37. WF-15.37 — Protected Capability Consumption
Where the Fabric Transfer Capability is single-use, usage-bounded,
size-bounded, or window-bounded, the Finality Sink performs or
coordinates the corresponding protected consumption operation.
A representative capability-state record comprises:
Das Expires 19 April 2027 [Page 636]
Internet-Draft Protected AI Execution Finality October 2026
capability_id;
authorized_transfer_digest;
source_domain_id;
destination_domain_id;
remaining_uses;
remaining_bytes;
last_sequence;
hardware_epoch;
state_version;
status.
For a single-use capability, a second incompatible transfer cannot
independently consume the same authorization state.
For a size-bounded capability, the hardware or protected controller
enforces the permitted data allowance.
For a rolling transfer capability, the system advances the protected
window or sequence state according to the authorized progression
rules.
A completed transfer cannot be undone merely by invalidating a
capability afterward.
11.15.38. WF-15.38 — Crash, Timeout, Reset, and Recovery
The system distinguishes interruptions at different stages of the
protected fabric-finality sequence.
Failure before protected validation: The proposed transfer remains
non-effective.
Failure before required evidence commitment: No valid corresponding
Fabric Transfer Capability becomes available.
Failure after protected commitment but before capability
installation: The protected system reconciles the committed
authorization state before reusing, recovering, or retiring the
capability.
Das Expires 19 April 2027 [Page 637]
Internet-Draft Protected AI Execution Finality October 2026
Failure before hardware admission: The transfer remains subject to
the required current capability verification.
Failure after partial transfer admission: The system determines which
bounded units may have crossed the controlled boundary.
Failure after device reset: The relevant hardware freshness and
protected capability-consumption state are verified before further
admission.
Failure after possible remote delivery: The operation may remain
indeterminate until suitable receiving-side completion evidence is
available.
A retry does not automatically obtain unrestricted authorization to
retransmit protected computation data.
Where supported, transfer identifiers, protected sequence counters,
hardware completion queues, authenticated acknowledgments, or
receiving-side admission records may support reconciliation.
The system does not assert unconditional exactly-once transfer
completion across arbitrary hardware fabrics.
11.15.39. WF-15.39 — Illustrative GPU-to-GPU Tensor Transfer
In one concrete implementation, a confidential AI training workload
executes across two accelerator domains.
A first GPU produces a tensor that must be transferred to a second
GPU for the next authorized computation stage.
The tensor remains resident in the source accelerator memory.
The transfer is submitted to an enforcement-controlled fabric
interface.
FI-1503 intercepts the proposed transfer.
HQ-1504 maintains an inactive transfer descriptor.
DF-1505 constructs the Candidate Fabric Transfer Act Descriptor
identifying the source GPU, destination GPU, tensor class, source
memory region, transfer size, route, approved workload graph, current
policy epoch, and designated fabric Finality Sink.
PED-1506 obtains the Cross-Domain Fabric Authorization Object.
Das Expires 19 April 2027 [Page 638]
Internet-Draft Protected AI Execution Finality October 2026
The PED validates the source-domain authority, destination-domain
authority, approved tensor class, graph relationship, route, transfer
envelope, policy state, and required freshness conditions.
The protected system performs the required authorization-state
operation and commits a Fabric Transfer LAVR or equivalent protected
validation record.
CR-1510 makes available the corresponding Fabric Transfer Capability.
The interconnect controller reconstructs or verifies the actual
transfer attributes.
The fabric Finality Sink verifies the capability against the actual
source, destination, tensor scope, route, memory region, size,
freshness, and protected state.
If the required conditions succeed, the hardware latch admits the
bounded transfer.
If the destination GPU or requested memory region differs from the
authorized scope, the transfer remains blocked.
The source GPU's ability to compute the tensor does not independently
confer authority to transfer it.
11.15.40. WF-15.40 — Illustrative DMA-Bypass Attempt
An AI workload is prohibited from exporting a protected accelerator
tensor into an unrestricted host memory region.
The normal software interface refuses the transfer.
The workload then attempts to use an alternative DMA descriptor or
device queue.
In the specified non-bypassable hardware-assisted implementation, the
relevant memory mappings, queues, and transfer interfaces are
controlled by the protected fabric enforcement arrangement.
The unauthorized descriptor cannot cause the governed transfer
without the required capability verification.
If an alternative DMA-capable interface remains accessible and can
export the tensor without passing the required enforcement, the
implementation does not satisfy the specified non-bypassable transfer
guarantee.
Das Expires 19 April 2027 [Page 639]
Internet-Draft Protected AI Execution Finality October 2026
This test distinguishes ordinary software permission checking from
actual protected hardware control of the effectuation path.
11.15.41. WF-15.41 — Illustrative Continuous Tensor-Stream Rollout
A distributed inference workload generates a sequence of key-value
cache transfer units for a cooperating accelerator.
The applicable Cross-Domain Fabric Authorization Object permits
transfers only between approved accelerator domains over a specified
fabric route and within a bounded transfer envelope.
The PED validates the initial transfer authorization and establishes
protected rolling-capability state.
The fabric Finality Sink verifies the required capability before
admitting each governed transfer unit or authorized transfer window.
During the sequence, the source workload attempts to redirect the
next transfer unit to another destination accelerator.
RM-1514 detects or the Finality Sink directly identifies the
destination change through its required transfer-context
verification.
The changed destination does not satisfy the current authorization
binding.
The next transfer unit is withheld.
Previously delivered transfer units remain completed effects.
The original authorization does not automatically permit continuation
over the substituted destination.
11.15.42. WF-15.42 — Illustrative Hardware Freshness and Replay Attack
An accelerator interconnect controller receives a Fabric Transfer
Capability bound to a specified protected hardware epoch and sequence
counter.
The capability permits one transfer of a protected tensor block.
The corresponding fabric Finality Sink verifies the capability and
permits the authorized transfer.
The protected usage or sequence state advances.
Das Expires 19 April 2027 [Page 640]
Internet-Draft Protected AI Execution Finality October 2026
An attacker subsequently resubmits the earlier capability, including
after an attempted device-state rollback.
The Finality Sink obtains the required current protected hardware-
freshness state.
The earlier capability no longer satisfies the mandatory freshness or
consumption conditions.
The replayed transfer is refused.
The result depends upon the freshness source being protected against
the rollback or reset behavior considered within the implementation's
threat model.
11.15.43. WF-15.43 — Alternative Technical Implementations
The protected fabric-transfer architecture may be implemented through
different technical substrates.
GPU memory-controller implementation: A protected memory interface
prevents unauthorized release of accelerator-resident tensors into
another governed memory domain.
Accelerator-interconnect implementation: A fabric controller verifies
bounded transfer authority before allowing accelerator-to-accelerator
communication.
DMA/IOMMU implementation: A protected DMA admission interface and
corresponding memory mappings prevent unverified transfers into
unauthorized memory regions.
SmartNIC implementation: A protected forwarding controller verifies
the required Fabric Transfer Capability before network transmission.
DPU implementation: A protected DPU control domain establishes
bounded transfer authority, while its controlled data path verifies
and enforces the authorized transfer.
Fabric-switch implementation: A switch pipeline maintains protected
forwarding or admission entries corresponding to scoped transfer
capabilities.
Optical-interconnect implementation: A protected optical path
controller enforces required transfer-admission authorization before
enabling the governed optical transfer.
Das Expires 19 April 2027 [Page 641]
Internet-Draft Protected AI Execution Finality October 2026
Confidential accelerator implementation: Protected accelerator memory
and authenticated transfer interfaces maintain the required finality
relationship across confidential-computing boundaries.
Single-node implementation: The PED, protected-state component,
capability mechanism, and fabric Finality Sink operate within one
protected accelerator or controller.
Distributed implementation: A protected authority issues or registers
a Fabric Transfer Capability that is independently verified by an
authenticated remote fabric or receiving-side component.
Cold-path/fast-path implementation: Higher-cost authorization occurs
through a protected controller, while a local hardware mechanism
enforces compact capability checks on the latency-sensitive transfer
path.
The selected implementation determines the actual guarantees against
privileged host compromise, firmware compromise, device reset,
hardware tampering, fabric routing attacks, and unauthorized
alternative transfer paths.
A software-only implementation does not automatically provide
hardware-latched protection.
11.15.44. WF-15.44 — Failure and Fail-Closed Conditions
The fabric Finality Sink refuses the governed transfer when a
mandatory condition is absent, invalid, expired, revoked, replayed,
inconsistent, or unverifiable.
Non-limiting refusal conditions include:
(a) missing Cross-Domain Fabric Authorization Object;
(b) invalid source-domain authority;
(c) invalid destination-domain authority;
(d) unauthorized computation-data class;
(e) source or destination accelerator measurement mismatch;
(f) workload or tenant identity mismatch;
(g) unauthorized memory region;
(h) transfer-size violation;
Das Expires 19 April 2027 [Page 642]
Internet-Draft Protected AI Execution Finality October 2026
(i) unapproved collective-operation class;
(j) invalid workload graph;
(k) unauthorized fabric route;
(l) switch-identity mismatch;
(m) jurisdictional mismatch where mandatory;
(n) invalid runtime transfer envelope;
(o) stale policy epoch;
(p) invalid revocation state;
(q) failed protected-state transition;
(r) failed required Fabric Transfer LAVR or ZK-LAVR commitment;
(s) missing Fabric Transfer Capability;
(t) invalid capability authentication;
(u) unauthorized capability reuse;
(v) expired or replayed nonce;
(w) hardware-freshness mismatch;
(x) incompatible boot or fabric epoch;
(y) exhausted transfer allowance;
(z) designated Finality Sink mismatch; or
(aa) unavailable required hardware verification machinery.
The corresponding transfer remains blocked, held, or otherwise non-
effective.
An implementation may separately authorize safe recovery or a
reduced-scope operation, but failure of the original required
authorization does not create unrestricted transfer permission.
Das Expires 19 April 2027 [Page 643]
Internet-Draft Protected AI Execution Finality October 2026
11.15.45. WF-15.45 — PHOSITA Verification and Negative Tests
A person having ordinary skill in accelerator architecture, GPU
security, hardware fabrics, DMA/RDMA systems, SmartNICs, DPUs,
protected computing, cryptography, and high-performance AI
infrastructure may verify the described architecture through
controlled testing.
Test 1 — Authorized transfer: Submit a transfer satisfying the
required source, destination, data-class, route, state, and
capability conditions. The fabric Finality Sink admits the bounded
transfer.
Test 2 — Missing capability: Present an otherwise valid transfer
descriptor without the required Fabric Transfer Capability.
Hardware-associated admission is refused.
Test 3 — Source substitution: Present a capability from an
unauthorized source accelerator. Required source-domain verification
fails.
Test 4 — Destination substitution: Redirect a validated tensor
transfer to an unauthorized destination accelerator. Destination
verification fails.
Test 5 — Tenant mismatch: Attempt cross-tenant transfer outside the
authorized scope. Protected validation refuses the operation.
Test 6 — Tensor-class mismatch: Substitute a protected tensor class
not authorized by the capability. Transfer admission fails.
Test 7 — Memory-region substitution: Change the source or destination
memory region where region identity is mandatory. Finality Sink
verification rejects the change.
Test 8 — Transfer-size anomaly: Exceed the authorized transfer-size
or byte allowance. Hardware admission rejects the unauthorized
excess.
Test 9 — Collective-operation mismatch: Attempt an unapproved
collective-operation type. Required workload-graph validation fails.
Test 10 — Fabric-route substitution: Change the transfer route
outside the authorized scope. The Finality Sink refuses the
transfer.
Das Expires 19 April 2027 [Page 644]
Internet-Draft Protected AI Execution Finality October 2026
Test 11 — Switch mismatch: Attempt transfer through an unauthorized
fabric switch where switch identity is mandatory. Verification
fails.
Test 12 — Hardware latch: Present a transfer while the protected
hardware admission condition remains disabled. No governed transfer
occurs.
Test 13 — Authorized latch release: Supply a valid bounded capability
and verify that the hardware enables only the permitted transfer.
Test 14 — DMA bypass: Attempt an alternate DMA path around the
controlled interface. The transfer is blocked or subjected to
equivalent mandatory finality verification.
Test 15 — Host-memory export: Attempt to copy accelerator-resident
protected data into an unauthorized host memory region. The governed
transfer is refused.
Test 16 — Continuous transfer: Transfer several authorized bounded
units while verifying the applicable rolling capability or window
state.
Test 17 — Route drift: Change the destination route between transfer
windows. Further unauthorized units are withheld.
Test 18 — Graph deviation: Introduce a source-destination
relationship outside the approved workload graph. The next affected
transfer is refused.
Test 19 — Transfer-window replay: Reuse an earlier consumed transfer-
window authorization. Protected sequence or usage verification
fails.
Test 20 — Hardware-counter replay: Re-present a capability bound to
an earlier protected hardware-counter value. Verification fails
where freshness advancement is mandatory.
Test 21 — Device reset: Reset the device and attempt to reuse
authority bound to an incompatible earlier boot epoch. Required
freshness verification fails.
Test 22 — Policy revocation: Revoke the mandatory transfer permission
before admission. The affected operation remains blocked.
Test 23 — Concurrent grant consumption: Submit competing transfers
against one restricted authorization. Protected state prevents
unauthorized double consumption.
Das Expires 19 April 2027 [Page 645]
Internet-Draft Protected AI Execution Finality October 2026
Test 24 — Evidence failure: Interrupt mandatory Fabric Transfer
validation-evidence commitment. No valid corresponding transfer
capability becomes available.
Test 25 — Cold-path/fast-path separation: Perform higher-cost
authority validation outside the latency-sensitive path and verify
that every governed transfer still requires its applicable local
admission check.
Test 26 — Protected lookup tampering: Attempt to alter a hardware
capability-table entry from an unauthorized software context. The
protected table rejects the modification under the declared threat
model.
Test 27 — Expired route grant: Present a transfer after the
capability's mandatory validity period has expired. Local
verification refuses admission.
Test 28 — Crash after partial transfer: Interrupt a multi-unit
transfer and verify that the protected recovery procedure
distinguishes completed units from pending or indeterminate units.
Test 29 — Single-node finality: Implement validation and transfer
enforcement within one protected device while preserving the required
authorization and effectuation functions.
Test 30 — Distributed fabric finality: Issue transfer authorization
from a protected authority node and independently verify it at a
remote fabric or receiving-side Finality Sink.
Test 31 — Alternate accelerator interface: Attempt the same governed
data movement through another available accelerator API or device
interface. The operation remains mediated or blocked.
Test 32 — Revocation during streaming: Revoke a mandatory
authorization condition during an ongoing bounded transfer.
Subsequent affected transfer units are withheld according to the
specified authorization granularity.
Test 33 — Unauthorized capability reuse across sinks: Present a
capability issued for one fabric Finality Sink at another protected
interface. Required sink binding fails.
Test 34 — Cold-path outage: Make the protected authority unavailable
while the fast path receives a new transfer outside any valid
existing bounded grant. The fast path refuses unauthorized
admission.
Das Expires 19 April 2027 [Page 646]
Internet-Draft Protected AI Execution Finality October 2026
Test 35 — Actual-operation descriptor substitution: Validate one DMA
descriptor, replace mandatory fields before effectuation, and verify
that the hardware-associated Finality Sink rejects the mismatch.
The tests may employ accelerator emulators, controlled GPU workloads,
DMA test devices, IOMMU test environments, programmable fabric
switches, SmartNIC/DPU development platforms, protected
authorization-state services, hardware counters, transfer-sequence
instrumentation, and fault-injection facilities.
The verification establishes only the properties implemented and
demonstrated under the specified trust model.
11.15.46. WF-15.46 — Claim-Specific Technical Support
Enforcement Point 48 — Protected Cross-Domain AI-Fabric Transfer
Finality System
The workflow describes:
(a) AC-1501 and DC-1502 representing source and destination compute,
accelerator, or memory domains;
(b) FI-1503 providing hardware-associated transfer interception;
(c) HQ-1504 maintaining the proposed cross-domain transfer in a Non-
Effective State;
(d) DF-1505 constructing a Candidate Fabric Transfer Act Descriptor;
(e) PED-1506 validating the Cross-Domain Fabric Authorization Object,
source and destination authority, data classification, approved
workload graph, fabric route, transfer envelope, and policy state;
(f) EV-1509 generating or committing a Fabric Transfer LAVR, ZK-LAVR,
or other applicable protected evidence;
(g) CR-1510 releasing or making available the scoped Fabric Transfer
Capability;
(h) FS-1512 independently verifying the capability before governed
transfer admission; and
(i) refusal when required capability or authorization conditions
fail.
Enforcement Point 49 — Fabric Transfer Descriptor Granularity
Das Expires 19 April 2027 [Page 647]
Internet-Draft Protected AI Execution Finality October 2026
WF-15.8 through WF-15.9 identify the source and destination
accelerator measurements, workload and tenant identities, model
identity, tensor class, memory region, transfer size, collective-
operation type, fabric route, switch identity, jurisdiction, policy
epoch, nonce, expiry, and fabric Finality Sink identity.
Enforcement Point 50 — Hardware-Latched Transfer Admission
WF-15.24 through WF-15.25 describe hardware-disabled or non-admitting
fabric lanes, switch entries, DMA queues, optical paths, memory
interfaces, and accelerator transfer interfaces that become enabled
only upon required capability verification.
Enforcement Point 51 — Continuous Tensor or Memory-Transfer
Validation
WF-15.26 through WF-15.29 describe bounded packets, blocks, tensor
slices, memory pages, collective-operation phases, and transfer
windows; rolling capabilities or protected receipts; and withholding
of subsequent units upon mandatory route, destination, size, or
workload-graph violations.
Enforcement Point 52 — Hardware-Freshness Binding
WF-15.30 through WF-15.32 describe binding to accelerator counters,
sequence numbers, secure switch state, trusted time, monotonic
counters, boot epochs, or protected device state and rejection of
replay outside the authorized freshness context.
Enforcement Point 53 — Separated Cold-Path Validation and Line-Rate
Finality
WF-15.33 through WF-15.35 describe higher-cost protected
authorization away from the latency-sensitive path and mandatory
bounded local checks through protected lookup entries, sequence
counters, short-lived authentication tags, route grants, DMA
descriptors, and queue-pair capabilities.
11.15.47. WF-15.47 — Technical Effect
The disclosed workflow establishes a protected causal relationship
between:
(a) AI computation producing protected accelerator-resident data;
(b) preparation of a proposed cross-domain transfer;
(c) interception before the governed fabric-finality boundary;
Das Expires 19 April 2027 [Page 648]
Internet-Draft Protected AI Execution Finality October 2026
(d) maintenance of the Candidate Fabric Transfer Act in a Non-
Effective State;
(e) construction of a transfer-specific descriptor;
(f) authentication of the Cross-Domain Fabric Authorization Object;
(g) protected validation of source authority, destination authority,
data classification, workload graph, transfer envelope, fabric route,
policy state, and required hardware freshness;
(h) protected authorization-state handling;
(i) Fabric Transfer LAVR, ZK-LAVR, or equivalent protected evidence
commitment;
(j) scoped Fabric Transfer Capability availability;
(k) independent capability verification at the hardware-associated
fabric Finality Sink;
(l) hardware-latched admission of only the authorized transfer;
(m) protected rolling authorization where continuous transfers are
governed; and
(n) fail-closed withholding when any mandatory authorization
condition is absent or invalid.
The architecture prevents an AI accelerator from treating possession
of model parameters, tensors, gradients, embeddings, key-value
caches, inference context, or other protected computation data as
sufficient authority to transfer that data across an independently
governed domain boundary.
The hardware-latched embodiment places the required transfer-
enablement condition within, or in mandatory control of, the actual
hardware transfer path.
The continuous-transfer embodiment prevents authorization of one
bounded unit from becoming unrestricted permission for subsequent
unauthorized transfer units.
The hardware-freshness embodiment restricts replay or reuse of an
earlier authorization outside its permitted device-state context.
Das Expires 19 April 2027 [Page 649]
Internet-Draft Protected AI Execution Finality October 2026
The cold-path/fast-path embodiment allows more computationally
expensive authorization to occur outside a latency-sensitive transfer
path while retaining mandatory bounded capability verification before
the governed transfer is admitted.
Computation is not authority to act.
Possession of a tensor is not authority to transfer it.
An authorized compute workload is not automatically an authorized
cross-domain data sender.
Hardware connectivity is not protected transfer authorization.
Cold-path approval does not replace mandatory verification at the
fabric Finality Sink.
11.16. WF-16 — Distributed Hardware-Watchdog Execution Interlock,
Protected Monitoring-State Attestation, Multi-Sink Revocation
Fencing, Fail-Closed Monitoring Failure, and Effectuation-State-
Preserving Quarantine
11.16.1. WF-16.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture in which an out-of-band monitoring domain
cooperates with a Protected Enforcement Domain and a plurality of
independently enforceable Finality Sinks to govern consequential
operations generated or requested by an artificial-intelligence
execution environment.
The system distinguishes observation of an artificial-intelligence
workload from authority to permit a consequential operation.
An out-of-band security component may detect execution anomalies,
integrity failures, unauthorized tool activities, authority-scope
deviations, or other monitored conditions.
However, the monitoring component's observation or detection does not
independently constitute execution authorization.
Instead, a protected monitoring-state record represents the
applicable measured or evaluated condition of the monitored workload.
A Protected Enforcement Domain receives and validates the monitoring-
state record and evaluates it together with the operation-specific
authority conditions of a proposed Candidate Act.
Das Expires 19 April 2027 [Page 650]
Internet-Draft Protected AI Execution Finality October 2026
Where the required conditions succeed, the protected system
establishes the applicable authorization-state transition, commits
required protected validation evidence, and releases or makes
available an execution-enabling capability bound to the Candidate
Act, monitoring-state version, protected authorization state, and
designated Finality Sink.
Each applicable Finality Sink independently verifies the required
capability and monitoring-state condition before permitting the
governed operation to become effective.
If the mandatory monitoring state becomes stale, revoked,
unavailable, inconsistent, or invalid, the affected Finality Sink
refuses effectuation.
The architecture separates:
(a) artificial-intelligence computation;
(b) out-of-band observation and anomaly detection;
(c) protected monitoring-state authentication;
(d) operation-specific protected authorization;
(e) scoped execution-capability issuance;
(f) independent effectuation-boundary verification;
(g) revocation and prevention of further unauthorized operations;
(h) quarantine of the affected workload or resource; and
(i) preservation of accurate operation-completion and recovery state.
The system does not presume that a watchdog stopping future inference
or quarantining a workload retroactively prevents an operation that
has already become effective.
Monitoring is not execution authority.
11.16.2. WF-16.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises:
AE-1601 — Artificial-Intelligence Execution Domain
Das Expires 19 April 2027 [Page 651]
Internet-Draft Protected AI Execution Finality October 2026
An AI-agent runtime, model-serving environment, agentic workflow,
autonomous process, tool-execution environment, container, virtual
machine, accelerator workload, or corresponding computing domain
configured to generate or process consequential operations.
WM-1602 — Out-of-Band Monitoring Domain
A monitoring and security component operating outside the unilateral
execution authority controlled by AE-1601.
The component may comprise a protected processor, data processing
unit, secure controller, isolated accelerator, hardware-assisted
monitor, or equivalent independent security mechanism.
MC-1603 — Monitoring-State Collection Component
A component configured to collect or obtain permitted execution
measurements, status information, policy observations, integrity
events, behavioral indicators, or associated monitoring evidence.
MG-1604 — Protected Monitoring-State Generator
A mechanism configured to produce a protected monitoring-state record
representing the relevant monitored workload condition.
MS-1605 — Protected Monitoring-State Store
A protected or authenticated mechanism maintaining monitoring-state
identifiers, versions, validity conditions, enforcement-state
indicators, and associated authenticity or freshness information.
DC-1606 — Candidate Act Descriptor Component
A mechanism configured to construct or verify a machine-readable
representation of a consequential operation requested by AE-1601.
HQ-1607 — Non-Effective Candidate Act Holding Mechanism
An enforcement-controlled queue, buffer, pending request object,
inactive command, or equivalent mechanism retaining a proposed
consequential operation before effectuation.
PED-1608 — Protected Enforcement Domain
A protected authority component configured to evaluate the applicable
Candidate Act Descriptor, Authority Object, monitoring-state version,
protected authorization state, and required runtime conditions.
Das Expires 19 April 2027 [Page 652]
Internet-Draft Protected AI Execution Finality October 2026
PS-1609 — Protected Authorization-State Store
A protected mechanism maintaining policy epochs, revocation versions,
operation-specific grants, nonce state, capability usage,
authorization-state references, and required validation commitments.
EV-1610 — Protected Validation-Evidence Component
A mechanism configured to generate or commit an operation-specific
protected validation record, LAVR, authenticated receipt, sealed
commitment, or equivalent evidence.
CR-1611 — Execution-Enabling Capability Mechanism
A protected component configured to issue, register, activate, or
otherwise make available a scoped execution capability bound to the
applicable Candidate Act and required monitoring-state version.
RF-1612 — Protected Revocation-Fence Component
A mechanism configured to advance or invalidate applicable
monitoring-state and authorization versions and to prevent
capabilities bound to superseded mandatory state from enabling
subsequent consequential operations.
FS-1613 — Network Finality Sink
A protected network interface, egress controller, gateway, NIC,
SmartNIC, DPU-controlled forwarding interface, or equivalent
effectuation boundary.
FS-1614 — Tool and API Finality Sink
A protected tool executor, API gateway, function executor, connector,
or equivalent effectuation interface.
FS-1615 — Credential and Storage Finality Sink
A protected credential-use interface, database commit controller,
persistent storage interface, or equivalent consequential boundary.
FS-1616 — Additional Effectuation Finality Sink
A payment interface, accelerator-output controller, physical
actuator, device interface, or other independently governed
effectuation boundary.
QC-1617 — Quarantine Controller
Das Expires 19 April 2027 [Page 653]
Internet-Draft Protected AI Execution Finality October 2026
A component configured to impose authorized restrictions on agent
computation, tool invocation, infrastructure access, network
activity, or other specified workload functions.
OS-1618 — Protected Operation-Outcome Store
A protected mechanism maintaining pending, reserved, confirmed-
effective, denied, revoked, quarantined, or indeterminate operation
states.
RC-1619 — Recovery and State-Revalidation Component
A protected mechanism configured to determine whether failed or
unavailable monitoring-state conditions can be restored through
authorized revalidation or recovery.
SC-1620 — Cross-Component State-Consistency Component
A mechanism configured to maintain or verify the required
correspondence among monitoring-state versions, Candidate Act
identities, policy epochs, capability states, and the Finality Sinks
participating in governed effectuation.
The components may be physically separated, colocated, integrated
into one protected hardware node, or distributed across multiple
authenticated execution and enforcement environments.
The out-of-band monitoring function need not itself be the Finality
Sink.
The corresponding security guarantee depends upon the required
protected monitoring condition being enforced at the actual
consequential boundary.
11.16.3. WF-16.3 — Establishment of the Monitoring and Execution Trust
Boundaries
Before governed AI operations are processed, the system establishes a
trust boundary between AE-1601 and WM-1602.
The AI execution environment may perform computation, produce model
outputs, prepare commands, select tools, and request consequential
operations.
However, it cannot unilaterally:
(a) modify authenticated monitoring-state records;
Das Expires 19 April 2027 [Page 654]
Internet-Draft Protected AI Execution Finality October 2026
(b) advance or roll back protected monitoring-state versions;
(c) create valid protected monitoring attestations;
(d) override required revocation conditions;
(e) issue unrestricted execution capabilities;
(f) replace protected Finality Sink verification logic;
(g) bypass mandatory monitoring-state-dependent authorization; or
(h) restore previously invalidated execution authority merely by
restarting the workload.
WM-1602 may obtain monitoring information through protected
telemetry, authenticated execution reports, hardware measurements,
secured system interfaces, or another suitable mechanism.
The selected implementation determines the monitoring domain's actual
visibility and trust properties.
Out-of-band placement alone does not establish that the monitoring
component observes every relevant workload event.
The architecture enforces only the monitoring conditions and
effectuation interfaces actually covered by the implementation.
11.16.4. WF-16.4 — Definition of Out-of-Band Monitoring
For this embodiment, out-of-band monitoring refers to observation,
measurement, collection, or evaluation occurring through a component
logically isolated from the monitored workload's unilateral execution
authority.
The monitoring mechanism may observe:
(a) workload integrity;
(b) software or model configuration;
(c) unauthorized tool activity;
(d) agent policy violations;
(e) runtime behavioral anomalies;
(f) unexpected privilege use;
Das Expires 19 April 2027 [Page 655]
Internet-Draft Protected AI Execution Finality October 2026
(g) prohibited communication patterns;
(h) abnormal infrastructure access;
(i) protected component availability;
(j) watchdog resets;
(k) hardware fault conditions; or
(l) other governance-relevant execution state.
The monitoring domain may support protective decisions by producing
authenticated monitoring evidence.
However, an out-of-band observation is not automatically an inline
enforcement action.
A condition observed after a consequential operation completes cannot
retroactively prevent that operation.
Accordingly, the protected system treats monitoring-state information
as an input to mandatory operation-specific effectuation
authorization when the corresponding claim requires prevention before
external effect.
11.16.5. WF-16.5 — Identification of Governed Consequential Boundaries
The system identifies the classes of consequential operations for
which monitoring-state-dependent authorization is mandatory.
These may include:
(a) external network transmission;
(b) API dispatch;
(c) privileged credential application;
(d) persistent storage commitment;
(e) tool execution;
(f) payment instruction;
(g) accelerator-state export;
(h) device actuation; and
Das Expires 19 April 2027 [Page 656]
Internet-Draft Protected AI Execution Finality October 2026
(i) other protected effectuation operations.
in the implementation described by enforcement point 62, at least two
distinct effectuation classes are governed by independently
enforceable Finality Sinks.
For example, the same AI workload may be permitted to generate both
network requests and persistent database mutations.
The corresponding network Finality Sink and database Finality Sink
separately verify the execution authority required for their own
effectuation interfaces.
Authorization for one effectuation class does not automatically
authorize another class.
11.16.6. WF-16.6 — Mandatory Effectuation-Path Coverage
The protected system configures the governed effectuation interfaces
so that the AI workload cannot complete a specified consequential
operation through an accessible bypass path that omits required
Finality Sink verification.
A representative arrangement may include:
(a) sandboxed workload execution;
(b) restricted host access;
(c) mandatory network-egress mediation;
(d) controlled privileged tool execution;
(e) protected credential custody;
(f) governed database-write interfaces;
(g) hardware-associated accelerator export controls; and
(h) protected actuator or device interfaces.
The system identifies each effectuation path capable of producing the
governed consequence.
If an operation can bypass the selected Finality Sink through another
available interface, the implementation must restrict or equivalently
mediate that alternative path to establish the specified enforcement
property.
Das Expires 19 April 2027 [Page 657]
Internet-Draft Protected AI Execution Finality October 2026
A watchdog that merely reports suspicious execution does not provide
non-bypassable effectuation control.
11.16.7. WF-16.7 — Monitoring-State Collection
MC-1603 obtains monitoring information associated with AE-1601.
An illustrative observation record comprises:
workload_id;
monitor_id;
execution_domain_id;
software_measurement;
runtime_policy_reference;
observation_class;
observation_value;
observation_time;
monitor_sequence;
monitor_health_state.
The selected monitoring mechanism determines which measurements are
available and their trustworthiness.
For example, a protected hardware monitor may obtain device or
infrastructure state not directly writable by the AI workload.
A software monitor may observe process events or tool invocations,
subject to its operating-system isolation and visibility limitations.
The system does not assume that all monitoring implementations can
inspect encrypted application payloads, hidden model reasoning, or
every downstream operation.
Required authorization predicates are selected according to
information that the implementation can actually authenticate or
verify.
Das Expires 19 April 2027 [Page 658]
Internet-Draft Protected AI Execution Finality October 2026
11.16.8. WF-16.8 — Protected Monitoring-State Record
MG-1604 constructs a protected monitoring-state record.
in the implementation described by enforcement point 62, the record
includes:
(a) workload identity;
(b) monitoring-state version;
(c) validity condition; and
(d) enforcement-state indicator.
An illustrative record comprises:
monitor_record_id;
workload_identity;
monitoring_domain_identity;
monitoring_state_version;
policy_epoch;
observation_digest;
measured_execution_condition;
enforcement_state;
valid_from;
valid_until;
sequence_number;
nonce;
revocation_reference;
protected_authentication.
The enforcement-state indicator may identify a policy-defined state
such as:
Das Expires 19 April 2027 [Page 659]
Internet-Draft Protected AI Execution Finality October 2026
MONITOR_VALID;
MONITOR_RESTRICTED;
MONITOR_REVOKED;
MONITOR_UNAVAILABLE;
MONITOR_RECOVERY_PENDING; or
MONITOR_QUARANTINED.
These labels are illustrative implementation states rather than
mandatory terminology for every embodiment.
The protected state identifies whether the record may satisfy the
required monitoring predicate of a particular Candidate Act.
A record identifying a healthy workload does not independently grant
unrestricted authority over all consequential operations.
11.16.9. WF-16.9 — Monitoring-State Versioning
The system associates each protected monitoring-state record with a
version, generation, protected sequence, or equivalent authenticated
state identifier.
An illustrative progression is:
M_v → M_(v+1)
where:
M_v denotes the earlier protected monitoring state; and
M_(v+1) denotes the later protected monitoring state.
Version advancement may occur when:
(a) a new monitoring evaluation is committed;
(b) a relevant policy violation is detected;
(c) a protected execution state changes;
(d) a workload enters quarantine;
(e) monitoring authority is revoked;
Das Expires 19 April 2027 [Page 660]
Internet-Draft Protected AI Execution Finality October 2026
(f) a protected monitoring component is restarted under a new
authenticated generation; or
(g) another required monitoring-state transition occurs.
The versioning mechanism must distinguish a current authorized state
from a superseded state when the corresponding claim requires that
distinction.
An untrusted workload cannot independently restore an earlier
monitoring-state version to recover invalidated execution authority.
11.16.10. WF-16.10 — Hardware-Attested Monitoring State
in the implementation described by enforcement point 63, the
monitoring-state record comprises a cryptographically authenticated
measurement or attestation generated by WM-1602.
A non-limiting attested record may include:
monitoring_domain_id;
protected_hardware_identity;
workload_id;
measurement_digest;
monitoring_state_version;
enforcement_state;
sequence_number;
freshness_nonce;
validity_interval;
attestation_signature;
attestation_chain_reference.
The Protected Enforcement Domain verifies the required authenticity,
workload association, version or sequence, and freshness.
A cryptographic signature alone does not prove that the record
describes the correct workload or current monitoring state.
Das Expires 19 April 2027 [Page 661]
Internet-Draft Protected AI Execution Finality October 2026
The corresponding verification includes the required relationship
between the attested monitoring component and the workload whose
operations are being authorized.
11.16.11. WF-16.11 — Protected Attestation Verification
PED-1608 evaluates the monitoring-state attestation.
An illustrative predicate is:
MonitorAttestValid = SignatureValid AND WorkloadBound AND
VersionValid AND FreshnessValid AND MonitorAuthorized
where:
SignatureValid verifies the authenticated monitoring record;
WorkloadBound verifies association with the correct AI execution
domain;
VersionValid verifies the required monitoring-state generation;
FreshnessValid verifies the authorized validity interval or sequence;
MonitorAuthorized verifies that the record originated from an
accepted monitoring authority.
The protected system additionally checks applicable revocation or
policy state when mandatory.
If the record cannot establish a required predicate, it is not
treated as valid authorization evidence.
The implementation's trust in hardware attestation extends only to
the properties covered by the attested measurement and the applicable
trust chain.
11.16.12. WF-16.12 — Candidate Act Generation
AE-1601 generates or requests a consequential operation.
The operation may comprise:
(a) an HTTPS request;
(b) an API invocation;
(c) a shell or tool command;
Das Expires 19 April 2027 [Page 662]
Internet-Draft Protected AI Execution Finality October 2026
(d) a credential-mediated service call;
(e) a database write;
(f) an artifact deployment;
(g) an accelerator memory transfer;
(h) a payment instruction; or
(i) an actuator command.
The proposed operation is classified as Candidate Act CA-1621.
Generation of CA-1621 does not independently confer execution
authority.
The existence of a valid monitoring-state record also does not
independently authorize the operation.
The Candidate Act remains subject to its operation-specific authority
and Finality Sink conditions.
11.16.13. WF-16.13 — Interception and Non-Effective Staging
The applicable interception mechanism receives CA-1621 before the
operation crosses its governed effectuation boundary.
HQ-1607 maintains CA-1621 in a Non-Effective State.
An illustrative staging record comprises:
candidate_act_id;
workload_id;
operation_class;
operation_reference;
target_finality_sink;
monitoring_state_reference;
policy_epoch;
status = NON_EFFECTIVE.
Das Expires 19 April 2027 [Page 663]
Internet-Draft Protected AI Execution Finality October 2026
Where the Candidate Act includes mutable parameters, the system
retains an immutable operation representation or authenticated digest
sufficient to verify the actual effectuation request.
The agent cannot independently release the operation merely because
the watchdog has reported a normal monitoring condition.
Protected authorization remains mandatory.
11.16.14. WF-16.14 — Candidate Act Descriptor Formation
DC-1606 constructs a canonical Candidate Act Descriptor representing
the consequential operation.
An illustrative descriptor comprises:
candidate_act_id;
requesting_workload_identity;
operation_class;
target_resource;
destination_or_recipient;
operation_parameters;
payload_digest;
authorized_purpose;
authority_object_reference;
monitoring_state_version;
monitoring_record_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_id.
Das Expires 19 April 2027 [Page 664]
Internet-Draft Protected AI Execution Finality October 2026
Only attributes required by the applicable Authority Object or
specified embodiment are mandatory.
The descriptor identifies the specific requested operation rather
than merely identifying the monitored AI workload.
11.16.15. WF-16.15 — Canonical Descriptor and Monitoring-State Binding
In an illustrative cryptographic implementation:
Dwatch = Canon_v(W, ACT, TARGET, PARAM, MONITOR, EPOCH, F)
where:
Dwatch denotes the canonical Candidate Act Descriptor;
Canon_v denotes deterministic encoding under version v;
W denotes the authenticated workload identity;
ACT denotes the proposed consequential operation;
TARGET denotes its destination or resource;
PARAM denotes effectuation-relevant parameters;
MONITOR denotes the required monitoring-state reference and version;
EPOCH denotes protected policy and authorization-state information;
and
F denotes the designated Finality Sink.
An illustrative digest is:
hWatch = H("DAS-WATCHDOG-ACT-v1" || Encode(Dwatch))
where H denotes a cryptographic hash function.
The encoding must distinguish mandatory operation and monitoring-
state attributes without ambiguous interpretation.
The selected algorithms and serialization format are illustrative
implementation choices.
Das Expires 19 April 2027 [Page 665]
Internet-Draft Protected AI Execution Finality October 2026
11.16.16. WF-16.16 — Acquisition of Operation-Specific Authority
PED-1608 obtains the Authority Object applicable to CA-1621.
The Authority Object may specify:
(a) authorized workload identity;
(b) permitted operation class;
(c) authorized purpose;
(d) permitted destination or resource;
(e) applicable protected monitoring-state requirements;
(f) accepted monitoring-state versions;
(g) required attestation or freshness conditions;
(h) permitted Finality Sink;
(i) policy epoch;
(j) revocation conditions;
(k) nonce or usage restrictions;
(l) human approval where required; and
(m) additional operation-specific authorization predicates.
PED-1608 verifies the Authority Object and the required protected
monitoring record.
The watchdog's detection state is treated as an authorization input,
not as an unrestricted execution permission.
11.16.17. WF-16.17 — Combined Monitoring and Operation Authorization
PED-1608 evaluates the mandatory predicates required for CA-1621.
An illustrative predicate is:
Vwatch = Pworkload AND Poperation AND Pscope AND Pmonitor AND Pstate
AND Psink
where:
Das Expires 19 April 2027 [Page 666]
Internet-Draft Protected AI Execution Finality October 2026
Vwatch denotes the protected authorization result;
Pworkload verifies the requesting workload;
Poperation verifies the actual consequential operation;
Pscope verifies its permitted destination, resource, purpose, and
execution scope;
Pmonitor verifies the required monitoring-state record and version;
Pstate verifies policy, revocation, nonce, freshness, and protected
authorization state; and
Psink verifies the designated Finality Sink.
The system evaluates additional predicates where required.
Successful monitoring-state validation does not automatically
establish the remaining predicates.
A valid operation-specific Authority Object does not override a
failed mandatory monitoring-state condition.
All mandatory conditions must succeed before the required execution
capability becomes available.
11.16.18. WF-16.18 — Protected Authorization-State Transition
Upon successful protected validation, PED-1608 performs the required
authorization-state operation.
Such operations may include:
(a) verifying the current monitoring-state version;
(b) checking revocation state;
(c) reserving an operation-specific grant;
(d) consuming or registering a nonce;
(e) updating an operation quota;
(f) recording the protected monitoring-state reference;
(g) establishing a capability-use restriction;
Das Expires 19 April 2027 [Page 667]
Internet-Draft Protected AI Execution Finality October 2026
(h) registering the Candidate Act Descriptor digest; or
(i) performing another required protected-state transition.
Where a grant permits only one consequential operation, protected
state prevents incompatible concurrent requests from independently
consuming that grant.
Where the monitoring state becomes invalid during the authorization
transaction, the implementation ensures that the resulting capability
does not become usable contrary to the required current-state
conditions.
Failure of a mandatory protected-state transition prevents successful
capability availability.
11.16.19. WF-16.19 — Protected Validation-Evidence Commitment
EV-1610 generates or commits the protected validation evidence
required for CA-1621.
The evidence may comprise:
(a) a LAVR;
(b) an authenticated validation receipt;
(c) a sealed authorization record;
(d) a protected hash-chain commitment;
(e) a Merkle commitment;
(f) a protected state reference; or
(g) another supported validation-evidence mechanism.
An illustrative record contains:
receipt_id;
candidate_act_id;
descriptor_digest;
workload_id;
monitoring_state_version;
Das Expires 19 April 2027 [Page 668]
Internet-Draft Protected AI Execution Finality October 2026
monitoring_record_digest;
authority_object_reference;
protected_state_transition;
policy_epoch;
revocation_epoch;
finality_sink_id;
authorization_result;
protected_authentication.
Where the corresponding embodiment requires pre-effectuation
commitment, the evidence is committed before, or atomically with,
availability of the scoped execution capability.
An ordinary post-event monitoring log does not substitute for
required protected pre-effectuation validation evidence.
11.16.20. WF-16.20 — Protected Watchdog-Finality Transaction
The PED coordinates the required validation, state handling, evidence
commitment, and capability availability.
An illustrative transaction is:
(Snext, Rwatch, Ready) = CommitWatchdogFinality(Dwatch, A, Mv,
Scurrent, F)
where:
Snext denotes committed protected authorization state;
Rwatch denotes protected validation evidence;
Ready denotes satisfaction of mandatory pre-release conditions;
Dwatch denotes the Candidate Act Descriptor;
A denotes applicable authenticated authority;
Mv denotes the validated monitoring-state version;
Scurrent denotes prior protected authorization state; and
Das Expires 19 April 2027 [Page 669]
Internet-Draft Protected AI Execution Finality October 2026
F denotes the designated Finality Sink.
The capability-release mechanism does not treat an incomplete
mandatory commitment as successful authorization.
The transaction may be implemented through protected storage,
authenticated state machines, HSM-controlled procedures, or
equivalent protected state mechanisms.
Where the operation spans multiple services, the capability remains
unavailable until the required protected dependencies are verified.
11.16.21. WF-16.21 — Monitoring-State-Bound Execution Capability
CR-1611 generates or makes available a scoped execution capability.
An illustrative capability contains or securely references:
capability_id;
candidate_act_descriptor_digest;
authorized_workload_id;
monitoring_state_version;
monitoring_record_digest;
authorized_operation_scope;
policy_epoch;
revocation_epoch;
nonce;
expiry;
usage_limit;
protected_validation_record_digest;
finality_sink_id.
In a non-limiting cryptographic implementation:
Cwatch = Sign_skPED(Encode(hWatch, hR, Mv, Scope, Epoch, Rev, Nonce,
Expiry, F))
Das Expires 19 April 2027 [Page 670]
Internet-Draft Protected AI Execution Finality October 2026
where:
Cwatch denotes the scoped capability;
Sign_skPED denotes capability authentication under PED-controlled key
material;
hWatch denotes the Candidate Act Descriptor digest;
hR denotes the committed validation-evidence digest;
Mv denotes the required monitoring-state version;
Scope denotes the authorized operation scope;
Epoch denotes the policy epoch;
Rev denotes the applicable revocation-state reference;
Nonce denotes freshness;
Expiry denotes validity; and
F denotes the designated Finality Sink.
The capability may alternatively be implemented as a protected table
entry, sealed handle, authenticated execution permit, or hardware
enablement condition.
Its usability remains dependent upon the actual operation, mandatory
monitoring version, protected state, and applicable Finality Sink
verification.
11.16.22. WF-16.22 — Multiple Independently Enforceable Finality Sinks
in the implementation described by enforcement point 62, the
protected architecture includes independently enforceable Finality
Sinks associated with two or more consequential operation classes.
A representative configuration may comprise:
Network Finality Sink: Verifies the required capability before
permitting governed external transmission.
Tool/API Finality Sink: Verifies the required capability before
dispatching a privileged tool or API operation.
Das Expires 19 April 2027 [Page 671]
Internet-Draft Protected AI Execution Finality October 2026
Credential Finality Sink: Verifies the required capability before
applying protected credential material.
Storage Finality Sink: Verifies the required capability before
committing persistent data.
Payment Finality Sink: Verifies the required capability before
issuing a protected financial operation.
Accelerator Finality Sink: Verifies the required capability before
protected model-state or tensor export.
Actuator Finality Sink: Verifies the required capability before
enabling a governed physical-control operation.
Each applicable Finality Sink independently verifies the
authorization conditions required by its own effectuation interface.
An approval or capability for one effectuation class is not
automatically sufficient for another.
The monitoring-state record may be shared among multiple
authorization decisions, but each governed consequential operation
remains subject to the appropriate operation-specific capability and
Finality Sink checks.
11.16.23. WF-16.23 — Independent Finality Sink Verification
Before permitting CA-1621 to become effective, the designated
Finality Sink reconstructs or verifies the actual operation presented
for effectuation.
The Finality Sink verifies:
(a) capability authenticity;
(b) Candidate Act Descriptor correspondence;
(c) authorized workload identity;
(d) permitted operation class;
(e) destination or resource restrictions;
(f) required monitoring-state version;
(g) applicable monitoring-state validity;
Das Expires 19 April 2027 [Page 672]
Internet-Draft Protected AI Execution Finality October 2026
(h) current required policy epoch;
(i) revocation state;
(j) nonce and expiry;
(k) protected validation-evidence reference;
(l) capability usage or consumption state; and
(m) designated Finality Sink identity.
The operation is refused when a mandatory verification condition is
absent or invalid.
The Finality Sink does not treat a generic watchdog statement that
the workload is healthy as sufficient authorization for a concrete
external effect.
11.16.24. WF-16.24 — Monitoring-State-Aware Sink Predicate
An illustrative effectuation predicate is:
PermitSink = Auth(C) AND Match(C,Dactual) AND
MonitorValid(C,Mcurrent) AND StateValid(C,S) AND SinkValid(C,F)
where:
PermitSink denotes permission to effectuate the Candidate Act;
C denotes the scoped execution capability;
Dactual denotes the actual effectuation descriptor;
Mcurrent denotes the monitoring-state version and status required at
the Finality Sink;
S denotes current protected authorization state; and
F denotes the Finality Sink.
Auth verifies capability authenticity.
Match verifies exact or expressly authorized bounded operation
correspondence.
MonitorValid verifies the mandatory monitoring-state version,
freshness, and enforcement-state conditions.
Das Expires 19 April 2027 [Page 673]
Internet-Draft Protected AI Execution Finality October 2026
StateValid verifies required policy, revocation, validation evidence,
and usage state.
SinkValid verifies the designated effectuation boundary.
The operation becomes effective only when every mandatory predicate
succeeds.
11.16.25. WF-16.25 — Watchdog-Detected Violation
in the implementation described by enforcement point 64, WM-1602
detects a governance-relevant condition such as:
(a) execution-policy violation;
(b) authority-scope deviation;
(c) unauthorized tool activity;
(d) runtime-behavior anomaly;
(e) unauthorized privilege escalation;
(f) attempted execution-path bypass;
(g) invalid protected workload measurement; or
(h) another monitored condition specified by the applicable security
policy.
The monitoring domain records or authenticates the detected
condition.
The detected condition is submitted to the protected monitoring-state
and revocation machinery.
The corresponding action may include advancement of the protected
monitoring-state version, revocation of affected authorization,
restriction of further capability issuance, or quarantine.
The system does not presume that every detected anomaly necessarily
indicates an already completed unauthorized external effect.
11.16.26. WF-16.26 — Protected Revocation-Fence Advancement
RF-1612 advances the protected monitoring-state or revocation
version.
Das Expires 19 April 2027 [Page 674]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative transition is:
MONITOR_VERSION = v → v+1
where the new state invalidates capabilities that are no longer
permitted under the applicable protected monitoring policy.
A corresponding revocation record may contain:
workload_id;
previous_monitoring_version;
new_monitoring_version;
revocation_reason;
effective_policy_epoch;
affected_operation_classes;
affected_finality_sinks;
revocation_sequence;
protected_authentication.
The revocation mechanism prevents an affected capability bound to an
incompatible earlier state from being accepted for a new governed
consequential operation.
The revocation fence is effective only to the extent that the
participating Finality Sinks actually verify the required current
state or an authorized freshness-bounded equivalent.
A revocation record stored only in a monitoring log does not
independently prevent effectuation.
11.16.27. WF-16.27 — Enforcement of Superseded Monitoring Versions
Each affected Finality Sink verifies whether the capability's
monitoring-state version remains acceptable under the current
required authorization state.
An illustrative condition is:
MonitorVersionValid = AcceptedVersion(C.monitor_version,
CurrentProtectedMonitorState)
Das Expires 19 April 2027 [Page 675]
Internet-Draft Protected AI Execution Finality October 2026
where:
AcceptedVersion denotes the authorized version-verification rule;
C.monitor_version denotes the monitoring-state version bound to the
capability; and
CurrentProtectedMonitorState denotes the applicable protected
monitoring-state reference.
Where exact current-version matching is required, a capability bound
to a superseded version is rejected.
Where a protected authority permits a bounded freshness interval, the
Finality Sink verifies the corresponding authorized validity rule.
An expired or revoked version is not treated as acceptable merely
because the capability was previously valid.
The implementation must account for distributed propagation delay and
the actual freshness guarantees required by the claim.
11.16.28. WF-16.28 — Prevention Despite Continued or Interrupted Model
Access
in the implementation described by enforcement point 65, model-access
control is distinguishable from downstream Finality Sink enforcement.
An AI model may successfully complete an earlier inference operation
and produce a Candidate Act.
A watchdog may subsequently detect an execution anomaly and interrupt
further model access.
The already generated Candidate Act remains subject to downstream
Finality Sink verification.
Likewise, where the model remains available for permitted inference,
the downstream Finality Sink may independently refuse a consequential
operation because its monitoring-state or operation-specific
authorization conditions are invalid.
The architecture therefore does not require a model-access
interruption to be the sole means of preventing external effects.
A model-access gate may control further inference.
Das Expires 19 April 2027 [Page 676]
Internet-Draft Protected AI Execution Finality October 2026
A downstream Finality Sink controls the actual governed consequential
operation.
The two functions remain distinct.
11.16.29. WF-16.29 — Monitoring-State Unavailability
in the implementation described by enforcement point 66, the
protected system determines whether a mandatory monitoring-state
record is unavailable.
Unavailability may arise from:
(a) hardware watchdog failure;
(b) DPU or security-controller reset;
(c) loss of authenticated monitoring communication;
(d) monitoring-state storage failure;
(e) expired monitoring attestation;
(f) broken monitoring-state continuity;
(g) protected verification service outage; or
(h) another specified monitoring infrastructure failure.
Where current monitoring state is mandatory for an affected
consequential operation, unavailability does not create permission to
proceed.
The PED withholds the corresponding new execution capability or the
Finality Sink refuses it until an authorized recovery or revalidation
condition succeeds.
An unmonitored fallback path is not treated as safe solely because
the monitoring component is unavailable.
11.16.30. WF-16.30 — Stale and Inconsistent Monitoring-State Handling
The system evaluates whether the monitoring record is stale,
inconsistent, or outside the permitted freshness interval.
An illustrative predicate is:
Das Expires 19 April 2027 [Page 677]
Internet-Draft Protected AI Execution Finality October 2026
MonitoringAcceptable = Authentic(M) AND VersionValid(M) AND Fresh(M)
AND WorkloadMatch(M) AND EnforcementStateValid(M)
where:
M denotes the monitoring-state record.
Authentic verifies its required authentication.
VersionValid verifies monitoring-state version.
Fresh verifies its validity interval or protected sequence.
WorkloadMatch verifies association with the correct monitored
workload.
EnforcementStateValid verifies that the monitoring-state indicator
permits the requested operation under the applicable policy.
If a mandatory predicate fails, the affected Candidate Act remains
non-effective.
The protected system may request fresh monitoring evidence, use
another separately authorized monitoring source, or enter a protected
recovery procedure.
The absence of monitoring evidence is not interpreted as proof of a
healthy workload.
11.16.31. WF-16.31 — Protected Monitoring Recovery
RC-1619 coordinates recovery from invalid or unavailable monitoring
state.
The recovery procedure may require:
(a) authentication of the recovered monitoring component;
(b) verification of protected hardware or software measurements;
(c) establishment of a fresh monitoring generation;
(d) verification of workload identity;
(e) restoration or reconciliation of protected state;
(f) confirmation of current policy and revocation conditions;
Das Expires 19 April 2027 [Page 678]
Internet-Draft Protected AI Execution Finality October 2026
(g) invalidation of incompatible earlier monitoring records; and
(h) renewed operation-specific authorization.
The protected recovery procedure does not automatically restore
previously consumed, denied, expired, or revoked execution authority.
A fresh monitoring-state record may permit new authorization
evaluations when its mandatory predicates succeed.
It does not automatically release a pending Candidate Act without the
required operation-specific capability and Finality Sink
verification.
11.16.32. WF-16.32 — Quarantine Initiation
in the implementation described by enforcement point 67, QC-1617
receives a protected quarantine command or an authenticated
quarantine-state reference.
The quarantine command may arise from:
(a) a monitoring-policy violation;
(b) invalid workload attestation;
(c) revoked authorization state;
(d) an unsafe runtime condition;
(e) a protected operator decision;
(f) a security-controller decision; or
(g) another authorized containment condition.
The quarantine command identifies the affected workload, execution
domain, resources, permitted containment scope, and required
enforcement targets.
An illustrative quarantine record comprises:
quarantine_id;
workload_id;
quarantine_reason;
Das Expires 19 April 2027 [Page 679]
Internet-Draft Protected AI Execution Finality October 2026
monitoring_state_version;
policy_epoch;
affected_operation_classes;
affected_interfaces;
quarantine_start;
authorized_recovery_reference;
protected_authentication.
The quarantine record is an enforcement-state artifact, not an
unrestricted capability authorizing unrelated rollback or replay
operations.
11.16.33. WF-16.33 — Quarantine Enforcement
QC-1617 may restrict:
(a) further model inference;
(b) tool execution;
(c) external network transmission;
(d) credential-mediated operations;
(e) privileged connector access;
(f) infrastructure control;
(g) artifact deployment;
(h) accelerator-state export; or
(i) other governed workload functions.
The applicable containment mechanism may use:
(a) protected process suspension;
(b) sandbox restriction;
(c) network-egress blocking;
Das Expires 19 April 2027 [Page 680]
Internet-Draft Protected AI Execution Finality October 2026
(d) credential revocation;
(e) protected service-access controls;
(f) hardware forwarding restrictions;
(g) workload isolation;
(h) protected execution-policy changes; or
(i) another authorized containment mechanism.
The quarantine's actual prevention guarantee depends upon which
future effects the selected enforcement interfaces can block.
Quarantine does not retroactively undo a completed transmission,
payment, storage commitment, or physical actuation.
11.16.34. WF-16.34 — Preservation of Effectuation State During
Quarantine
OS-1618 preserves operation-specific status when quarantine occurs.
An illustrative state model comprises:
PENDING;
VALIDATING;
AUTHORIZED;
RESERVED;
EFFECTUATION_ATTEMPTED;
CONFIRMED_EFFECTIVE;
DENIED;
REVOKED;
QUARANTINED;
INDETERMINATE.
The system distinguishes:
Das Expires 19 April 2027 [Page 681]
Internet-Draft Protected AI Execution Finality October 2026
Pending Candidate Acts: Operations that have not yet crossed the
governed effectuation boundary and remain subject to required
authorization.
Confirmed-Effective Operations: Operations for which suitable
evidence establishes completion of the specified consequential
effect.
Indeterminate Operations: Operations that may have crossed the
effectuation boundary but whose completion cannot be established.
The quarantine mechanism does not rewrite a confirmed-effective
operation into a prevented operation.
It also does not assume that an indeterminate operation failed.
Pending operations remain non-effective unless separately authorized
under applicable current conditions.
11.16.35. WF-16.35 — No Automatic Rollback or Replay Authority
A quarantine command does not independently authorize:
(a) rollback of a completed transaction;
(b) cancellation of a previously completed payment;
(c) repeated execution of an uncertain operation;
(d) replay of an already consumed capability;
(e) restoration of revoked permissions;
(f) deletion of protected evidence;
(g) completion of an unverified Candidate Act; or
(h) another consequential recovery operation.
Where rollback or recovery produces a governed consequential effect,
the operation may itself constitute a new Candidate Act.
The applicable protected authority validates its scope, required
state, and effectuation boundary.
A previously valid capability does not automatically authorize an
unrelated rollback or repeated effectuation.
Das Expires 19 April 2027 [Page 682]
Internet-Draft Protected AI Execution Finality October 2026
11.16.36. WF-16.36 — Cross-Component Monitoring-State Consistency
Where multiple Finality Sinks participate, SC-1620 verifies the
required correspondence among their monitoring and authorization
states.
The relevant state may include:
(a) monitored workload identity;
(b) monitoring-state version;
(c) monitoring-state validity;
(d) protected revocation epoch;
(e) applicable policy epoch;
(f) Candidate Act identity;
(g) operation-specific capability identity;
(h) protected validation-evidence reference;
(i) usage or consumption state; and
(j) Finality Sink identity.
The implementation may use authenticated version records, protected
revocation services, signed state updates, protected local caches, or
equivalent mechanisms.
A participating Finality Sink must not treat an invalid required
state as valid merely because another component has not yet received
an update.
Where freshness-bounded caching is expressly permitted, the
implementation enforces the required validity interval.
When mandatory consistency cannot be established, the affected
operation remains blocked.
The embodiment does not automatically require globally instantaneous
synchronization or a single centralized authority.
Das Expires 19 April 2027 [Page 683]
Internet-Draft Protected AI Execution Finality October 2026
11.16.37. WF-16.37 — Illustrative Network and Storage Dual-Sink System
In one concrete implementation, an AI agent executes within a
protected cloud workload.
WM-1602 operates as an isolated security component monitoring the
workload.
The agent prepares two consequential operations:
First, an outbound HTTPS request.
Second, a persistent database modification.
The network request is associated with FS-1613.
The database modification is associated with FS-1615.
MG-1604 generates a protected monitoring-state record identifying the
monitored workload, monitoring-state version, validity interval, and
enforcement-state indicator.
For each Candidate Act, PED-1608 validates the applicable operation-
specific Authority Object and required current monitoring state.
Following successful authorization, the protected system commits the
required evidence and makes available a scoped capability for the
particular operation and Finality Sink.
The network Finality Sink verifies the capability applicable to the
HTTPS request.
The storage Finality Sink separately verifies the capability
applicable to the database modification.
Authorization of the network request does not independently authorize
the database commit.
If the monitoring-state version becomes invalid before the database
Finality Sink permits commitment, the database operation is refused
under the mandatory state rules.
The earlier network effect is not falsely treated as prevented if it
was already transmitted.
Das Expires 19 April 2027 [Page 684]
Internet-Draft Protected AI Execution Finality October 2026
11.16.38. WF-16.38 — Illustrative Watchdog-to-Finality Revocation
An AI agent receives valid authority to use a protected enterprise
API.
The PED issues an operation-specific capability bound to monitoring-
state version 25.
Before the agent submits the operation to its Finality Sink, the out-
of-band monitor detects an unauthorized privilege change.
The protected monitoring-state mechanism advances the required
monitoring version to 26 and records a revocation condition.
The affected API Finality Sink obtains the current protected
monitoring-state reference.
The previously issued capability remains bound to version 25.
The capability no longer satisfies the mandatory monitoring-state
predicate.
The Finality Sink refuses the API operation.
The prevention occurs at the effectuation boundary, not merely
because the watchdog generated an alert.
11.16.39. WF-16.39 — Illustrative Continued-Inference Scenario
An AI model remains available to perform inference.
During execution, it produces a proposed payment instruction.
The instruction is classified as a Candidate Act and staged.
A protected monitoring component detects an authority-scope anomaly
relevant to payment execution.
The monitoring-state version advances.
The payment Finality Sink verifies the current required monitoring
state before executing the payment.
The capability bound to the superseded state is rejected.
The payment does not become effective through the governed interface.
Das Expires 19 April 2027 [Page 685]
Internet-Draft Protected AI Execution Finality October 2026
The fact that the AI model may continue producing computational
output does not independently defeat the downstream protected
enforcement requirement.
11.16.40. WF-16.40 — Illustrative Watchdog Failure
An AI agent prepares an outbound credential-mediated operation.
Before protected authorization completes, the out-of-band monitoring
component becomes unavailable.
The applicable Authority Object requires a fresh authenticated
monitoring-state record.
PED-1608 cannot establish the required monitoring predicate.
The corresponding capability is withheld.
The Finality Sink refuses credential-mediated effectuation.
The protected recovery mechanism may attempt to restore the monitor,
establish a fresh authenticated state, and revalidate the operation.
The workload is not granted unrestricted credential use merely
because the watchdog failed.
11.16.41. WF-16.41 — Illustrative Quarantine After Possible External
Effect
An agent submits a network request through a governed egress
interface.
The interface accepts the authorized transmission, but the remote
service's final processing result is not available.
The out-of-band monitor subsequently detects suspicious behavior and
issues a quarantine condition.
The workload is restricted from further governed network operations.
OS-1618 records the earlier request as indeterminate if the available
evidence cannot establish remote completion.
The system does not automatically replay the request or claim that
quarantine prevented a request that may already have reached the
remote service.
Das Expires 19 April 2027 [Page 686]
Internet-Draft Protected AI Execution Finality October 2026
Any retry is subjected to protected recovery and duplicate-effect
prevention conditions.
This illustrates the distinction between prospective containment and
retrospective outcome determination.
11.16.42. WF-16.42 — Alternative Technical Implementations
The protected watchdog-to-finality arrangement may be implemented
through different substrates.
DPU monitoring implementation: A protected DPU performs monitoring
and provides authenticated monitoring-state information to the
applicable execution authority and Finality Sinks.
Secure-controller implementation: A hardware security controller or
isolated processor generates protected monitoring-state records.
Protected accelerator implementation: A separately controlled
accelerator or monitoring processor evaluates selected workload
conditions.
Host-assisted implementation: A privileged host-security service
observes an isolated agent runtime and supplies authenticated state,
subject to the host's actual isolation guarantees.
Network-enforcement implementation: A protected network gateway or
NIC verifies a monitoring-state-bound capability before transmission.
Credential-enforcement implementation: A protected credential broker
verifies the required monitoring and operation state before
credential application.
Storage-enforcement implementation: A protected database or storage
controller verifies the capability before committing a governed
mutation.
Multi-node implementation: A protected monitoring component and
several distributed Finality Sinks exchange authenticated state and
version information.
Single-node implementation: Monitoring, authorization, evidence
commitment, capability issuance, and local Finality Sink verification
operate within one protected node while retaining distinguishable
functional roles.
Das Expires 19 April 2027 [Page 687]
Internet-Draft Protected AI Execution Finality October 2026
Hardware-interlock implementation: A protected physical or device-
control interface requires the corresponding bounded capability
before actuation or transfer.
The selected implementation determines the actual isolation,
monitoring coverage, revocation propagation, bypass resistance, and
failure-recovery guarantees.
Out-of-band monitoring is not automatically equivalent to mandatory
inline enforcement.
11.16.43. WF-16.43 — Failure and Fail-Closed Conditions
The protected system refuses the governed operation when any
mandatory condition is absent, invalid, expired, revoked, stale,
inconsistent, replayed, or unverifiable.
Non-limiting denial conditions include:
(a) missing monitoring-state record;
(b) invalid monitoring-record authentication;
(c) workload identity mismatch;
(d) monitoring-domain identity mismatch;
(e) invalid attestation;
(f) replayed monitoring sequence;
(g) stale monitoring-state version;
(h) monitoring-state expiry;
(i) unavailable monitoring component;
(j) monitoring communication failure;
(k) unauthorized enforcement-state indicator;
(l) incompatible policy epoch;
(m) invalid revocation state;
(n) missing operation-specific Authority Object;
(o) invalid Candidate Act Descriptor;
Das Expires 19 April 2027 [Page 688]
Internet-Draft Protected AI Execution Finality October 2026
(p) unauthorized destination or operation class;
(q) failed protected-state transition;
(r) failed required validation-evidence commitment;
(s) missing execution-enabling capability;
(t) invalid capability authentication;
(u) monitoring version mismatch;
(v) capability expiry;
(w) capability replay;
(x) capability-consumption mismatch;
(y) Finality Sink identity mismatch;
(z) unavailable required Finality Sink verification; or
(aa) failure of mandatory enforcement-path coverage.
The affected Candidate Act remains non-effective, denied,
quarantined, or subject to an authorized recovery procedure.
A watchdog failure or security alert does not create authority to
bypass protected finality verification.
11.16.44. WF-16.44 — PHOSITA Verification and Negative Tests
A person having ordinary skill in hardware security, watchdog
systems, DPUs, secure controllers, protected computing, AI-agent
infrastructure, distributed authorization, revocation systems, and
execution-finality enforcement may verify the architecture through
controlled tests.
Test 1 — Valid monitoring state: Supply a current authenticated
monitoring record and a matching operation-specific capability. The
appropriate Finality Sink permits the authorized effect.
Test 2 — Missing monitoring state: Present a governed Candidate Act
without required monitoring evidence. Effectuation is refused.
Test 3 — Forged monitoring record: Present a record with invalid
protected authentication. PED validation fails.
Das Expires 19 April 2027 [Page 689]
Internet-Draft Protected AI Execution Finality October 2026
Test 4 — Wrong workload: Use a monitoring record associated with
another workload. Required workload binding fails.
Test 5 — Monitoring-version mismatch: Issue a capability for one
monitoring version and present it under an incompatible current
version. Finality Sink verification fails.
Test 6 — Stale monitoring record: Present a record beyond its
authorized freshness interval. The operation remains blocked.
Test 7 — Watchdog-to-finality revocation: Detect a required policy
violation, advance protected monitoring state, and verify rejection
of affected superseded capabilities.
Test 8 — Network Finality Sink: Present a valid monitoring record but
an invalid network operation capability. The transmission is
refused.
Test 9 — Storage Finality Sink: Present a valid network capability to
a separately governed storage interface. The storage commit is
refused.
Test 10 — Credential Finality Sink: Attempt protected credential use
after relevant monitoring-state revocation. The credential-mediated
effect is denied.
Test 11 — Continued inference: Permit further model computation while
withholding downstream operation authority. The protected Finality
Sink prevents the unauthorized effect.
Test 12 — Model interruption after output generation: Stop further
inference after a Candidate Act has been buffered. Verify that the
buffered operation remains subject to independent Finality Sink
authorization.
Test 13 — Hardware watchdog failure: Make the monitoring component
unavailable. Affected operations requiring fresh monitoring state
remain blocked.
Test 14 — Monitoring communication failure: Interrupt delivery of
required authenticated monitoring state. The protected system does
not assume continued validity beyond its permitted freshness
conditions.
Test 15 — Revocation propagation delay: Present an affected
capability at a distributed Finality Sink and verify enforcement of
the required current-state or freshness-bound rules.
Das Expires 19 April 2027 [Page 690]
Internet-Draft Protected AI Execution Finality October 2026
Test 16 — Capability replay: Reuse a consumed single-use capability.
Protected usage verification rejects it.
Test 17 — Concurrent capability use: Submit simultaneous operations
using one restricted grant. The protected system prevents
unauthorized double consumption.
Test 18 — Wrong Finality Sink: Present a capability for another
effectuation boundary. Required sink binding fails.
Test 19 — Quarantine before effectuation: Trigger quarantine while a
Candidate Act remains pending. The pending operation cannot bypass
protected authorization.
Test 20 — Quarantine after completed effect: Trigger quarantine after
a confirmed external operation. The completed effect remains
recorded as effective.
Test 21 — Quarantine with uncertain outcome: Interrupt a remote
operation after possible delivery and trigger quarantine. The
outcome is preserved as indeterminate until authorized
reconciliation.
Test 22 — Unauthorized rollback: Attempt rollback based solely on a
quarantine command. The operation is refused without its separately
required authority.
Test 23 — Unauthorized retry: Replay an uncertain consequential
operation without valid protected recovery authority. The duplicate
attempt is blocked.
Test 24 — Monitoring-state rollback: Restore an earlier monitoring-
state version through workload snapshot manipulation. Required
protected version verification rejects stale authority.
Test 25 — Invalid recovery attestation: Attempt restoration of
monitoring authority using an invalid component measurement.
Recovery fails.
Test 26 — Valid protected recovery: Reestablish a fresh authenticated
monitoring state and perform renewed operation-specific
authorization. Only the valid new operation is permitted.
Test 27 — Multiple effectuation classes: Verify that network, API,
credential, storage, or other designated Finality Sinks independently
enforce their own operation-specific capabilities.
Das Expires 19 April 2027 [Page 691]
Internet-Draft Protected AI Execution Finality October 2026
Test 28 — Monitoring alert without inline enforcement: Test an
implementation that merely reports violations. Confirm that alert
generation alone does not establish a protected prevention guarantee.
Test 29 — Single-node implementation: Implement protected monitoring,
authorization, and effectuation functions within one protected
controller. Verify the required functional separation and mandatory
effectuation checks.
Test 30 — Distributed implementation: Place the monitor, PED, and
several Finality Sinks on different nodes. Verify authenticated
monitoring-state association and operation-specific capability
enforcement.
Test 31 — Policy-state inconsistency: Present a valid-looking
capability with an incompatible required policy or revocation epoch.
The Finality Sink refuses effectuation.
Test 32 — Alternative-path bypass: Attempt the same governed
consequence through an accessible path not controlled by the selected
Finality Sink. The implementation blocks or equivalently mediates
the path.
The tests may be implemented through controlled AI workloads, mock
DPUs, protected controller emulators, authenticated monitoring
services, programmable Finality Sinks, versioned authorization-state
stores, network and storage test interfaces, fault injection,
hardware-reset simulation, and protected recovery instrumentation.
The tests establish the security properties of the actual enforcement
implementation under its stated trust assumptions.
11.16.45. WF-16.45 — Claim-Specific Technical Support
Enforcement Point 62 — Distributed Hardware-Watchdog Execution
Interlock System
The workflow describes:
(a) AE-1601 representing the artificial-intelligence execution
domain;
(b) WM-1602 representing the isolated out-of-band monitoring domain;
(c) MG-1604 generating a protected monitoring-state record comprising
workload identity, monitoring-state version, validity condition, and
enforcement-state indicator;
Das Expires 19 April 2027 [Page 692]
Internet-Draft Protected AI Execution Finality October 2026
(d) PED-1608 evaluating operation-specific authorization using the
protected monitoring-state record;
(e) multiple independently enforceable Finality Sinks associated with
distinct consequential operation classes;
(f) CR-1611 generating or making available a capability bound to the
Candidate Act, monitoring-state version, protected authorization
state, and Finality Sink;
(g) independent Finality Sink verification of the required capability
and monitoring state; and
(h) fail-closed refusal where mandatory monitoring state is invalid,
unavailable, stale, inconsistent, or revoked.
Enforcement Point 63 — Hardware-Attested Monitoring State
WF-16.10 through WF-16.11 describe cryptographic authentication or
hardware attestation of monitoring-state records and validation of
authenticity, workload association, version, and freshness.
Enforcement Point 64 — Watchdog-to-Finality Revocation Fence
WF-16.25 through WF-16.27 describe detection of monitored violations,
advancement of protected monitoring-state or revocation versions, and
rejection of capabilities bound to superseded required authorization
state.
Enforcement Point 65 — Prevention Despite Continued Model Access
WF-16.28 and WF-16.39 describe independent downstream Finality Sink
enforcement notwithstanding earlier successful inference, continued
model availability, or possession of previously generated model
output.
Enforcement Point 66 — Monitoring Failure and Stale-State Handling
WF-16.29 through WF-16.31 describe fail-closed handling of missing,
stale, invalid, or inconsistent monitoring records and protected
recovery or revalidation before accepting new affected execution
authority.
Enforcement Point 67 — Quarantine with Effectuation-State
Preservation
Das Expires 19 April 2027 [Page 693]
Internet-Draft Protected AI Execution Finality October 2026
WF-16.32 through WF-16.35 describe restricted post-detection
operation, preservation of confirmed-effective, pending, and
indeterminate states, and prohibition of automatic rollback, replay,
duplicate effectuation, or release of unverified operations.
11.16.46. WF-16.46 — Technical Effect
The disclosed workflow establishes a protected causal relationship
between:
(a) an AI execution domain generating or requesting a consequential
operation;
(b) an isolated out-of-band monitor producing authenticated
execution-state information;
(c) generation of a versioned protected monitoring-state record;
(d) mandatory interception and Non-Effective State staging of the
Candidate Act;
(e) construction of an operation-specific Candidate Act Descriptor;
(f) protected validation of applicable authority and the required
monitoring-state version;
(g) required protected authorization-state handling;
(h) protected validation-evidence commitment;
(i) generation or availability of a monitoring-state-bound execution
capability;
(j) independent capability and current-state verification at the
applicable Finality Sink;
(k) controlled consequential effectuation or fail-closed refusal;
(l) revocation-fence advancement when a mandatory monitored condition
becomes invalid; and
(m) quarantine and recovery preserving accurate operation-
effectuation state.
The architecture prevents a generic watchdog observation, a previous
model-access permission, or an ordinary agent authentication result
from substituting for the protected authorization required by a
specific consequential operation.
Das Expires 19 April 2027 [Page 694]
Internet-Draft Protected AI Execution Finality October 2026
The hardware-watchdog embodiment permits separately protected
monitoring to influence operation-specific authorization without
assuming that detection alone prevents external effects.
The revocation-fence embodiment causes capabilities bound to
invalidated monitoring state to fail the required subsequent Finality
Sink verification.
The multi-sink embodiment protects distinct network, tool,
credential, storage, financial, accelerator, and physical-control
boundaries according to their applicable authorization requirements.
The quarantine embodiment restricts future governed activity while
preserving the distinction between operations already completed,
operations still pending, and operations whose completion status is
uncertain.
Computation is not authority to act.
Monitoring is not authorization.
Detection is not prevention unless the relevant effectuation boundary
is actually controlled.
Stopping further inference does not retroactively prevent completed
downstream effects.
Quarantine does not authorize rollback, replay, or duplication of a
consequential operation.
11.17. WF-17 — Protected Confidential Virtual-Machine Execution,
Hardware-Rooted Composite ALF Validation, Workload-to-Act
Authorization, Privacy-Preserving Validation, Tenant-Bound
Capabilities, and Snapshot-Rollback-Resistant Finality
11.17.1. WF-17.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture governing externally effective operations
generated by an artificial-intelligence workload executing within a
confidential or virtualized cloud-computing environment.
The system provides a protected relationship between:
(a) an artificial-intelligence workload executing within a
confidential or isolated virtual machine;
Das Expires 19 April 2027 [Page 695]
Internet-Draft Protected AI Execution Finality October 2026
(b) machine-verifiable measurement of the workload's actual execution
context;
(c) protected validation of the measured model, software, workflow,
and policy state;
(d) interception and Non-Effective State staging of a proposed
consequential operation;
(e) independent protected authorization of the particular Candidate
Act;
(f) protected validation-evidence generation or commitment;
(g) scoped, non-bearer execution-capability availability; and
(h) independent Finality Sink verification before effectuation.
The protected execution environment may provide hardware-assisted
memory confidentiality, integrity protection, measured launch,
workload attestation, or other properties according to its
implementation.
Such properties protect specified aspects of computation but do not
independently establish authority for the workload to cause an
externally effective operation.
The AI workload may compute, generate outputs, prepare tools,
construct API requests, modify temporary state, and propose external
operations.
A governed Candidate Act remains in a Non-Effective State until its
applicable protected authorization conditions succeed and its
required execution capability verifies at the corresponding Finality
Sink.
The architecture additionally addresses:
(a) hardware-rooted Composite Algorithmic Logic Fingerprints;
(b) comparison of actual runtime-used model and workflow state with
approved conditions;
(c) privacy-preserving validation evidence;
(d) tenant and destination binding;
Das Expires 19 April 2027 [Page 696]
Internet-Draft Protected AI Execution Finality October 2026
(e) protected capability-consumption state outside rollback-
accessible workload snapshots; and
(f) crash, migration, restart, and virtual-machine snapshot recovery.
The embodiment is not limited to one confidential-computing vendor,
hypervisor, operating system, processor architecture, cryptographic
algorithm, or cloud provider.
11.17.2. WF-17.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
CV-1701 — Confidential or Isolated Virtual-Machine Execution
Environment
A confidential VM, isolated virtual machine, hypervisor-protected
workload, or equivalent virtualized execution environment hosting an
AI agent, model runtime, tool process, or agentic workflow.
AE-1702 — AI-Agent Compute Plane
An artificial-intelligence model, agent, planner, tool runtime, or
associated process executing within CV-1701 and configured to
generate Candidate Acts.
HM-1703 — Execution-Context Measurement Component
A component configured to obtain machine-verifiable measurements or
attestations associated with the VM, model, software configuration,
execution policy, workload identity, or other required runtime
context.
ALF-1704 — Composite ALF Construction and Verification Component
A mechanism configured to construct, obtain, or verify an Algorithmic
Logic Fingerprint incorporating applicable model, software, workflow,
policy, and hardware-related measurements.
IM-1705 — Candidate Act Interception Component
An enforcement-controlled interface configured to intercept a
proposed consequential operation before a governed cloud, host,
network, storage, or service effectuation boundary.
HQ-1706 — Non-Effective Holding Mechanism
Das Expires 19 April 2027 [Page 697]
Internet-Draft Protected AI Execution Finality October 2026
A controlled queue, buffer, pending request object, protected command
representation, or equivalent mechanism retaining a Candidate Act
until required protected authorization succeeds.
DC-1707 — Candidate Act Descriptor Component
A component configured to construct or verify a canonical, machine-
readable description of the actual proposed operation and its
finality-relevant context.
PED-1708 — Protected Enforcement Domain
An enforcement or authorization component isolated from unilateral
execution authority controlled by the AI workload and configured to
validate execution context, applicable authority, protected state,
and Candidate Act-specific predicates.
AS-1709 — Protected Authority and Policy Store
A protected mechanism maintaining Authority Objects, approved ALF
conditions, workload identity requirements, policy epochs, tenant
scope, revocation state, and authorized destination conditions.
PS-1710 — Protected Authorization-State Store
A protected mechanism maintaining nonce state, capability usage,
revocation epochs, validation commitments, execution-state versions,
and protected authorization transitions.
EV-1711 — Protected Validation-Evidence Component
A mechanism configured to generate or commit authenticated validation
evidence, including applicable LAVR, AVR, sealed receipt, or ZK-LAVR
representations.
CR-1712 — Scoped Capability Release Mechanism
A protected component configured to generate, register, derive,
release, or make available a scoped, non-bearer execution capability.
FS-1713 — Confidential Workload Finality Sink
A protected cloud, host, service-mesh, API, credential-release,
storage-commit, or network-transmission interface that verifies the
required execution capability before allowing the corresponding
consequential effect.
TC-1714 — Tenant and Destination Context Verifier
Das Expires 19 April 2027 [Page 698]
Internet-Draft Protected AI Execution Finality October 2026
A mechanism configured to verify the tenant, workload, virtual-
machine, destination service, and network-context bindings required
by the authorization.
RS-1715 — Rollback-Resistant Protected State Component
A protected mechanism maintaining required nonce, capability-
consumption, revocation, and hardware-freshness information outside
rollback-accessible portions of the AI workload.
OS-1716 — Protected Effectuation Outcome Store
A mechanism maintaining pending, authorized, reserved, denied,
confirmed-effective, indeterminate, expired, or revoked operation
state.
RC-1717 — Recovery and State-Reconciliation Component
A mechanism configured to reconcile protected authority, capability-
consumption, attestation, and operation-completion state following VM
restart, snapshot restoration, migration, or infrastructure failure.
The functions may be distributed or colocated.
The Protected Enforcement Domain may be implemented through a
protected host service, TEE, HSM, confidential governance component,
hardware controller, or other suitable enforcement arrangement.
The Finality Sink may be physically separate from or integrated with
the PED where the required distinct authorization and effectuation-
verification functions remain enforced.
11.17.3. WF-17.3 — Establishment of the Confidential-Computing Trust
Boundary
Before permitting governed AI operations, CV-1701 establishes the
applicable protected execution environment.
The selected implementation may provide:
(a) hardware-assisted memory encryption;
(b) protected workload memory integrity;
(c) measured virtual-machine launch;
(d) authenticated boot measurements;
Das Expires 19 April 2027 [Page 699]
Internet-Draft Protected AI Execution Finality October 2026
(e) virtual-machine attestation;
(f) protected workload identity;
(g) protected device configuration;
(h) isolated memory mappings; or
(i) another supported confidential-computing property.
The actual protection depends upon the processor, hypervisor,
firmware, launch protocol, attestation mechanism, and configured
threat model.
A confidential VM does not automatically prevent an authorized guest
process from issuing an unauthorized external operation.
Likewise, hardware protection of guest memory does not inherently
establish that an external network, credential, or storage interface
performs operation-specific authorization.
The system therefore establishes a separate protected execution-
finality boundary for each governed consequential operation.
11.17.4. WF-17.4 — Isolation of Protected Execution Authority
PED-1708 is configured so that AE-1702 cannot unilaterally modify the
protected authorization conditions required for its governed
Candidate Acts.
The AI workload may request authorization and supply measured context
or operation information.
However, it cannot independently:
(a) create valid protected capability-signing authority;
(b) modify required authorization-state records;
(c) restore consumed capabilities;
(d) invalidate mandatory Finality Sink verification;
(e) widen protected tenant permissions;
(f) replace approved ALF conditions;
(g) override protected revocation state; or
Das Expires 19 April 2027 [Page 700]
Internet-Draft Protected AI Execution Finality October 2026
(h) bypass a mandatory effectuation interface.
The PED may operate outside the guest VM, inside a separately
protected execution domain, or within a protected arrangement that
preserves the required isolation from the requesting agent.
Physical separation is not mandatory unless expressly required under
the specified enforcement profile.
11.17.5. WF-17.5 — Identification of Governed Effectuation Paths
The system identifies the operations for which confidential-workload
finality enforcement is required.
Such operations may include:
(a) outbound network transmission;
(b) privileged API invocation;
(c) credential release or application;
(d) persistent storage modification;
(e) database commitment;
(f) protected service invocation;
(g) model-output release;
(h) software deployment;
(i) cross-tenant data transfer; or
(j) another externally effective operation.
Each governed operation is associated with an appropriate Finality
Sink.
The implementation configures the applicable network, host, storage,
or service interfaces so that the AI workload cannot produce the
specified governed effect through an unrestricted alternative path.
A confidential VM that can independently use an unmediated external
interface does not satisfy the specified non-bypassable finality
guarantee for that interface.
Das Expires 19 April 2027 [Page 701]
Internet-Draft Protected AI Execution Finality October 2026
11.17.6. WF-17.6 — Execution-Context Measurement
HM-1703 obtains a machine-verifiable measurement or attestation of
the relevant VM and workload execution state.
The measurement may represent:
(a) VM launch identity;
(b) firmware or virtualized platform state;
(c) approved guest software;
(d) model identifier;
(e) model checkpoint state;
(f) adapter configuration;
(g) approved agent workflow;
(h) tool-access configuration;
(i) execution-policy configuration;
(j) protected workload identity; or
(k) another required runtime state.
The measurement source may comprise an attestation report,
authenticated software measurement, protected runtime-state record,
verified model artifact digest, or equivalent supported evidence.
The measurement need not cover every possible runtime component.
It must establish the properties actually required by the
corresponding authorization predicate.
11.17.7. WF-17.7 — Execution-Context Measurement Record
An illustrative measurement record comprises:
measurement_id;
vm_identity;
workload_identity;
Das Expires 19 April 2027 [Page 702]
Internet-Draft Protected AI Execution Finality October 2026
vm_measurement;
model_identifier;
checkpoint_digest;
adapter_digest;
tool_policy_reference;
workflow_reference;
execution_policy_reference;
policy_epoch;
measurement_generation;
attestation_nonce;
measurement_time;
protected_authentication.
The requesting workload may submit a reference to the record.
PED-1708 verifies the required authenticity and relationship to the
actual workload rather than accepting a caller-provided description
as authoritative.
A report authenticating the VM's launch state does not automatically
establish the integrity of every subsequently loaded model, plugin,
adapter, tool, or dynamically modified configuration.
Where those attributes are mandatory, additional authenticated
measurements or protected runtime checks are required.
11.17.8. WF-17.8 — Hardware-Rooted Composite ALF Formation
in the implementation described by enforcement point 74, ALF-1704
forms or verifies a Hardware-Rooted Composite Algorithmic Logic
Fingerprint.
The Composite ALF may identify one or more of:
(a) model identifier;
(b) checkpoint hash;
Das Expires 19 April 2027 [Page 703]
Internet-Draft Protected AI Execution Finality October 2026
(c) adapter hash;
(d) tokenizer configuration;
(e) decoder configuration;
(f) system-instruction policy;
(g) safety configuration;
(h) tool-permission graph;
(i) retrieval-source graph;
(j) orchestration graph;
(k) virtual-machine measurement;
(l) hardware attestation report; and
(m) policy epoch.
The fingerprint combines the selected model, workflow, software, and
hardware-related measurements into an authenticated or verifiable
authorization condition.
Only the attributes required by the corresponding claim and Authority
Object are mandatory for a given implementation.
An approved base-model identifier does not necessarily establish that
the current adapter, tool graph, safety configuration, or system-
instruction policy is also approved.
11.17.9. WF-17.9 — Composite ALF Cryptographic Representation
In an illustrative implementation:
Dalf = Canon_v(Model, Checkpoint, Adapter, Tokenizer, Decoder,
Instructions, Safety, Tools, Retrieval, Workflow, VM, Attestation,
Epoch)
where:
Dalf denotes the canonical Composite ALF descriptor;
Canon_v denotes deterministic encoding under version v;
Model denotes the selected model identity;
Das Expires 19 April 2027 [Page 704]
Internet-Draft Protected AI Execution Finality October 2026
Checkpoint denotes the required checkpoint measurement;
Adapter denotes adapter state;
Tokenizer and Decoder denote applicable model processing
configurations;
Instructions denotes system-instruction policy;
Safety denotes the relevant safety configuration;
Tools denotes approved tool permissions;
Retrieval denotes authorized retrieval sources;
Workflow denotes the approved orchestration graph;
VM denotes the required virtual-machine measurement;
Attestation denotes authenticated hardware-related evidence; and
Epoch denotes the protected policy epoch.
An illustrative digest is:
hALF = H("DAS-HARDWARE-COMPOSITE-ALF-v1" || Encode(Dalf))
where H denotes a cryptographic hash function.
The selected serialization must distinguish materially different
values under the applicable authorization semantics.
The formula is a non-limiting implementation example.
The original ALF mechanism does not require this particular encoding,
digest label, or fixed field set in every embodiment.
11.17.10. WF-17.10 — Authentication of the Measurement Source
PED-1708 determines whether the supplied measurement or attestation
originates from an acceptable authority.
The verification may involve:
(a) attestation signature validation;
(b) trusted hardware identity;
Das Expires 19 April 2027 [Page 705]
Internet-Draft Protected AI Execution Finality October 2026
(c) certificate-chain validation;
(d) workload identity association;
(e) nonce or challenge freshness;
(f) approved virtual-machine measurement;
(g) applicable measurement generation; and
(h) protected revocation state.
An illustrative predicate is:
AttestationValid = AuthenticReport AND TrustedMeasurementSource AND
CorrectWorkload AND FreshChallenge AND AcceptableState
where each term represents a required attestation property.
Successful attestation means only that the supported and verified
measurement claims are acceptable.
It does not independently authorize every consequential operation
requested by the attested workload.
11.17.11. WF-17.11 — Runtime-Used Configuration Verification
in the implementation described by enforcement point 75, the
protected system verifies the model and workflow configuration
actually used by the requesting AI workload.
The required validation may compare:
(a) loaded model identity;
(b) checkpoint digest;
(c) adapter digest;
(d) tool-permission graph;
(e) retrieval configuration;
(f) orchestration graph;
(g) execution-policy state;
(h) applicable system-instruction policy; and
Das Expires 19 April 2027 [Page 706]
Internet-Draft Protected AI Execution Finality October 2026
(i) other mandatory runtime measurements.
PED-1708 compares the runtime-used configuration with the
corresponding approved measurement or ALF condition.
A successful VM attestation does not automatically override a
mismatch between the actual runtime-used configuration and the
approved authorization state.
Where a mandatory configuration measurement fails, the corresponding
Candidate Act remains non-effective.
11.17.12. WF-17.12 — Distinguishing Launch Attestation from Runtime
Integrity
A virtual machine may initially launch under an approved measurement.
After launch, its runtime configuration may change.
Such changes may include:
(a) loading a different model checkpoint;
(b) activating another adapter;
(c) widening tool permissions;
(d) replacing an agent workflow;
(e) modifying retrieval sources;
(f) changing system instructions;
(g) replacing a policy configuration; or
(h) activating a new executable plugin.
Where the applicable authorization requires measurement of the
changed attribute, PED-1708 obtains or verifies current authenticated
runtime evidence.
An earlier launch attestation alone is insufficient when it does not
cover the runtime state required by the Candidate Act's
authorization.
The implementation may use protected runtime measurements,
authenticated configuration records, measured load events, or
equivalent mechanisms.
Das Expires 19 April 2027 [Page 707]
Internet-Draft Protected AI Execution Finality October 2026
The reliability of these measurements depends upon the trust and
tamper-resistance properties of the selected measurement source.
11.17.13. WF-17.13 — Candidate Act Generation
AE-1702 performs permitted computation within CV-1701.
The AI workload produces a proposed consequential operation.
Non-limiting operations include:
(a) a confidential-data transmission;
(b) an API request;
(c) a protected credential-use request;
(d) a cross-tenant service invocation;
(e) a database modification;
(f) a storage write;
(g) a deployment instruction; or
(h) another governed consequential operation.
The proposed operation is classified as Candidate Confidential-
Workload Act CA-1718.
The fact that CA-1718 originates from an attested confidential VM
does not independently establish protected execution authority.
11.17.14. WF-17.14 — Interception and Non-Effective Staging
IM-1705 receives or intercepts CA-1718 before the governed effect
occurs.
HQ-1706 retains the operation in a Non-Effective State.
An illustrative staging record comprises:
candidate_act_id;
vm_identity;
workload_identity;
Das Expires 19 April 2027 [Page 708]
Internet-Draft Protected AI Execution Finality October 2026
operation_class;
request_reference;
target_resource;
destination_reference;
runtime_measurement_reference;
policy_epoch;
finality_sink_id;
status = NON_EFFECTIVE.
The operation remains blocked pending protected authorization.
Where the requested operation contains mutable parameters, the
interception component may hold an immutable representation or
authenticated digest.
The AI workload cannot validate one operation and substitute
materially different required parameters immediately before
effectuation without renewed verification.
11.17.15. WF-17.15 — Candidate Act Descriptor Construction
DC-1707 constructs a machine-readable Candidate Act Descriptor
representing the proposed consequential operation.
The descriptor may include:
candidate_act_id;
requesting_vm_identity;
workload_identity;
tenant_identity;
operation_class;
destination_service_identity;
destination_network_context;
target_resource;
Das Expires 19 April 2027 [Page 709]
Internet-Draft Protected AI Execution Finality October 2026
operation_parameters;
payload_digest;
authorized_purpose;
composite_alf_reference;
attestation_reference;
runtime_measurement_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry;
authority_object_reference;
finality_sink_id.
Only the fields required under the specified enforcement profile or
Authority Object must participate in authorization.
The descriptor is distinct from the underlying Candidate Act and from
the attestation or execution capability.
11.17.16. WF-17.16 — Canonical Candidate Act Descriptor
In an illustrative cryptographic implementation:
Dconf = Canon_v(VM, W, T, ACT, TARGET, PARAM, MEASURE, POLICY, EPOCH,
F)
where:
Dconf denotes the confidential-workload Candidate Act Descriptor;
VM denotes the authenticated virtual-machine identity;
W denotes the workload identity;
T denotes the tenant identity;
ACT denotes the requested consequential operation;
Das Expires 19 April 2027 [Page 710]
Internet-Draft Protected AI Execution Finality October 2026
TARGET denotes the destination or resource;
PARAM denotes operation parameters;
MEASURE denotes required ALF and attestation context;
POLICY denotes protected authority or execution-policy context;
EPOCH denotes current required authorization-state versions; and
F denotes the designated Finality Sink.
An illustrative descriptor digest is:
hConf = H("DAS-CONFIDENTIAL-ACT-v1" || Encode(Dconf))
The selected deterministic encoder ensures that materially different
operations are distinguishable under the required authorization
rules.
The protected authorizer and Finality Sink employ compatible
descriptor interpretation.
The expression is an implementation example rather than a universal
requirement for every DAS embodiment.
11.17.17. WF-17.17 — Acquisition of Applicable Authority
PED-1708 obtains the Authority Object applicable to CA-1718 from
AS-1709 or another authenticated authority source.
The Authority Object may define:
(a) authorized VM identity;
(b) permitted workload identity;
(c) tenant scope;
(d) authorized model or workflow condition;
(e) approved ALF requirement;
(f) required hardware or runtime attestation;
(g) permitted operation class;
(h) authorized execution purpose;
Das Expires 19 April 2027 [Page 711]
Internet-Draft Protected AI Execution Finality October 2026
(i) allowed destination or resource;
(j) credential scope;
(k) policy epoch;
(l) revocation conditions;
(m) nonce or usage restrictions; and
(n) designated Finality Sink identity.
The PED authenticates the authority information and evaluates its
applicable protected state.
The AI agent cannot create additional execution authority merely by
supplying an attestation report or requesting a broader operation.
11.17.18. WF-17.18 — Protected Runtime and Operation Authorization
PED-1708 evaluates the mandatory authorization predicates for CA-
1718.
An illustrative conjunctive predicate is:
Vconf = Pvm AND Pworkload AND PALF AND Pruntime AND Poperation AND
Pscope AND Pstate
where:
Vconf denotes the protected authorization result;
Pvm verifies required virtual-machine identity or attestation;
Pworkload verifies requesting workload identity;
PALF verifies the Approved Composite ALF Condition;
Pruntime verifies the actual required runtime-used configuration;
Poperation verifies the proposed consequential operation;
Pscope verifies tenant, purpose, destination, resource, and permitted
operation scope; and
Pstate verifies required policy, revocation, freshness, nonce, and
protected authorization state.
Das Expires 19 April 2027 [Page 712]
Internet-Draft Protected AI Execution Finality October 2026
Where alternative or threshold conditions are authorized, the PED
evaluates the corresponding permitted policy combination.
Failure of any mandatory predicate prevents release of the required
execution capability.
11.17.19. WF-17.19 — Protected Authorization-State Operations
Upon successful predicate validation, PED-1708 performs the protected
authorization-state operations required for CA-1718.
These may include:
(a) verifying the current policy epoch;
(b) checking protected revocation state;
(c) reserving an operation-specific authorization grant;
(d) consuming or registering a nonce;
(e) advancing a protected usage counter;
(f) binding the operation to the current VM generation;
(g) registering a validation-evidence commitment;
(h) recording a capability-consumption reference; or
(i) another protected authorization transition.
Where a grant is single-use, the protected mechanism prevents
incompatible concurrent operations from independently consuming the
same authorization.
Where a protected-state operation cannot be completed consistently,
the corresponding capability remains unavailable.
11.17.20. WF-17.20 — Protected Validation-Evidence Commitment
EV-1711 generates or commits the validation evidence required for CA-
1718.
A non-limiting evidence record may contain:
receipt_id;
candidate_act_id;
Das Expires 19 April 2027 [Page 713]
Internet-Draft Protected AI Execution Finality October 2026
candidate_act_descriptor_digest;
vm_attestation_reference;
approved_alf_reference;
runtime_measurement_reference;
authority_object_reference;
tenant_identity;
destination_scope;
policy_epoch;
protected_state_transition;
nonce;
finality_sink_id;
decision;
protected_authentication.
The evidence may comprise a cryptographically authenticated
validation receipt, sealed commitment, LAVR, AVR, or other supported
protected representation.
Where the corresponding embodiment requires evidence commitment as a
prerequisite to capability release, the protected commitment occurs
before, or atomically with, availability of the scoped execution
capability.
An ordinary post-event audit log does not replace the required
protected validation-evidence dependency.
11.17.21. WF-17.21 — Protected Confidential-Workload Finality
Transaction
The PED coordinates the required validation, protected-state
handling, evidence commitment, and capability availability.
An illustrative transaction is:
(Snext, Rconf, Ready) = CommitConfidentialFinality(Dconf, A, M,
Scurrent, F)
Das Expires 19 April 2027 [Page 714]
Internet-Draft Protected AI Execution Finality October 2026
where:
Snext denotes the committed protected authorization state;
Rconf denotes protected validation evidence;
Ready denotes the indication that required release conditions have
completed;
Dconf denotes the validated Candidate Act Descriptor;
A denotes authenticated authority context;
M denotes the required runtime measurement and ALF state;
Scurrent denotes the prior protected authorization state; and
F denotes the designated Finality Sink.
A valid execution capability is not made available when a mandatory
protected commitment remains incomplete.
The implementation may employ transactional protected storage,
sealed-state machinery, hardware-backed state, an HSM-controlled
procedure, or equivalent protected mechanisms.
Where participating components do not share one atomic storage
transaction, the capability remains unavailable until the required
committed dependencies have been verified.
11.17.22. WF-17.22 — Scoped Non-Bearer Execution Capability
Following successful completion of the required protected finality
transaction, CR-1712 makes available a scoped, non-bearer execution
capability.
A non-limiting capability may contain or securely reference:
capability_id;
candidate_act_descriptor_digest;
vm_identity;
workload_identity;
tenant_identity;
Das Expires 19 April 2027 [Page 715]
Internet-Draft Protected AI Execution Finality October 2026
authorized_operation;
destination_scope;
runtime_measurement_reference;
approved_alf_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry;
usage_limit;
validation_evidence_digest;
finality_sink_id.
An illustrative cryptographic implementation is:
Cconf = Sign_skPED(Encode(hConf, hR, VM, W, Tenant, Scope, ALF,
Epoch, Nonce, Expiry, F))
where:
Cconf denotes the execution capability;
Sign_skPED denotes authenticated capability generation under PED-
controlled key material;
hConf denotes the Candidate Act Descriptor digest;
hR denotes the validation-evidence commitment digest;
VM denotes the VM identity;
W denotes the workload identity;
Tenant denotes the authorized tenant;
Scope denotes permitted operation and destination scope;
ALF denotes the required approved logic reference;
Das Expires 19 April 2027 [Page 716]
Internet-Draft Protected AI Execution Finality October 2026
Epoch denotes the policy epoch;
Nonce denotes freshness;
Expiry denotes the capability validity limit; and
F denotes the authorized Finality Sink.
The capability may alternatively comprise a protected capability-
table entry, authenticated execution permit, sealed handle, or
hardware-controlled enablement condition.
A signature alone does not establish non-bearer operation unless the
required context, scope, state, and Finality Sink conditions are
actually enforced.
11.17.23. WF-17.23 — Privacy-Preserving Protected Validation Evidence
in the implementation described by enforcement point 76, the
protected validation evidence may comprise a cryptographically
authenticated receipt or zero-knowledge validation receipt.
The evidence establishes satisfaction of required authority or
runtime-integrity predicates while restricting disclosure of
designated protected information.
Such information may include:
(a) confidential internal policy;
(b) private user attributes;
(c) proprietary model configuration;
(d) approved workflow parameters;
(e) protected attestation details;
(f) private enterprise authorization rules; or
(g) another protected validation input.
Where a ZK-LAVR is used, the implementation employs an actual proof
construction or other expressly supported mechanism establishing the
specified proof properties.
Das Expires 19 April 2027 [Page 717]
Internet-Draft Protected AI Execution Finality October 2026
The corresponding verifier checks the required proof statement,
cryptographic authenticity, Candidate Act association, and capability
context.
A signed validation receipt may establish authenticated compliance
evidence without providing formal zero-knowledge confidentiality.
These guarantees are distinguished according to the selected
cryptographic construction.
11.17.24. WF-17.24 — Confidential Validation and Finality Sink
Independence
The protected authorization mechanism may validate private
information without requiring that information to be disclosed to the
Finality Sink.
For example, PED-1708 may verify a confidential enterprise policy and
generate protected evidence that the operation satisfied the required
authorization predicates.
FS-1713 may verify:
(a) the evidence authentication;
(b) the required cryptographic proof where applicable;
(c) the Candidate Act Descriptor commitment;
(d) the scoped execution capability;
(e) required current protected authorization state; and
(f) the actual operation presented for effectuation.
The Finality Sink need not receive the full private policy if the
authenticated evidence and protected authorization mechanism provide
the required verifiable relationship.
However, the Finality Sink must still verify all fields and
conditions that the applicable embodiment requires it to enforce.
The privacy-preserving evidence does not replace mandatory capability
verification.
Das Expires 19 April 2027 [Page 718]
Internet-Draft Protected AI Execution Finality October 2026
11.17.25. WF-17.25 — Independent Finality Sink Verification
FS-1713 receives or reconstructs the actual consequential operation
and obtains the corresponding scoped capability.
The Finality Sink verifies:
(a) capability authenticity;
(b) actual Candidate Act Descriptor correspondence;
(c) required VM identity;
(d) workload identity;
(e) tenant identity;
(f) authorized operation class;
(g) destination service or resource;
(h) applicable runtime authorization state;
(i) required policy epoch;
(j) revocation state;
(k) nonce and expiry;
(l) protected validation-evidence commitment;
(m) capability usage or consumption state; and
(n) designated Finality Sink identity.
The operation proceeds only when the mandatory verification
conditions succeed.
A valid confidential VM attestation is not accepted as a substitute
for the required Candidate Act-specific execution capability.
11.17.26. WF-17.26 — Finality Sink Verification Predicate
An illustrative predicate is:
PermitConf = Auth(C) AND Match(C,Dactual) AND RuntimeValid(C,M) AND
TenantValid(C,T) AND StateValid(C,S) AND SinkValid(C,F)
Das Expires 19 April 2027 [Page 719]
Internet-Draft Protected AI Execution Finality October 2026
where:
PermitConf denotes permission to effectuate the Candidate Act;
C denotes the scoped non-bearer execution capability;
Dactual denotes the actual effectuation descriptor;
M denotes the required runtime measurement or approved ALF state;
T denotes the actual tenant and destination context;
S denotes the applicable protected authorization state; and
F denotes the designated Finality Sink.
Auth verifies capability authentication.
Match verifies exact correspondence or permitted bounded-scope
matching.
RuntimeValid verifies the mandatory measured execution-context
conditions.
TenantValid verifies required tenant and destination bindings.
StateValid verifies policy, revocation, freshness, validation
evidence, and usage conditions.
SinkValid verifies that the capability authorizes the selected
Finality Sink.
The Candidate Act is permitted only when all mandatory predicates
succeed.
11.17.27. WF-17.27 — Tenant and Destination Scope Binding
in the implementation described by enforcement point 77, the
Candidate Act Descriptor identifies:
(a) tenant context;
(b) cloud-workload identity;
(c) requesting virtual-machine identity;
(d) destination service identity;
Das Expires 19 April 2027 [Page 720]
Internet-Draft Protected AI Execution Finality October 2026
(e) destination network context; and
(f) applicable policy epoch.
The corresponding execution capability is associated with the
authorized tenant and destination conditions.
An illustrative tenant-context record comprises:
tenant_id;
workload_id;
vm_id;
destination_service_id;
destination_network_context;
authorized_resource_scope;
policy_epoch;
finality_sink_id.
The Finality Sink compares the actual operation against the required
tenant and destination scope.
A capability issued for one tenant does not authorize an operation
for another tenant when tenant binding is mandatory.
Likewise, a capability for an approved destination service does not
authorize an unauthorized destination or network context.
11.17.28. WF-17.28 — Cross-Tenant Authority Isolation
In a multi-tenant cloud implementation, several AI workloads may
execute on shared physical infrastructure.
Each workload may have its own:
(a) virtual-machine identity;
(b) tenant identity;
(c) approved ALF condition;
(d) authority scope;
Das Expires 19 April 2027 [Page 721]
Internet-Draft Protected AI Execution Finality October 2026
(e) policy epoch;
(f) protected capability state; and
(g) permitted destinations.
The protected enforcement mechanism ensures that a capability issued
for one tenant cannot authorize effectuation for another tenant
outside its permitted scope.
Tenant authorization is evaluated against authenticated tenant and
workload context, not merely against a tenant identifier supplied by
the requesting application.
Physical coexistence on the same host does not establish shared
execution authority.
A request attempting to substitute another tenant's destination,
credential scope, or resource identity fails the corresponding
mandatory authorization predicate.
11.17.29. WF-17.29 — Virtual-Machine Snapshot Rollback Threat
in the implementation described by enforcement point 78, the
architecture addresses restoration of an earlier virtual-machine
snapshot.
A snapshot may contain:
(a) agent process memory;
(b) previously issued capability references;
(c) application authorization data;
(d) locally stored nonces;
(e) cached policy information;
(f) pending operations;
(g) runtime configuration; and
(h) prior application state.
Restoring the snapshot may return the guest workload to an earlier
apparent state.
Das Expires 19 April 2027 [Page 722]
Internet-Draft Protected AI Execution Finality October 2026
However, the restoration must not recover execution authority
previously consumed, revoked, expired, or otherwise invalidated under
mandatory protected conditions.
The system therefore separates required authoritative capability-
consumption, nonce, or hardware-freshness state from the rollback-
accessible portion of the AI workload.
11.17.30. WF-17.30 — Protected Rollback-Resistant State
RS-1715 maintains the protected state required to prevent
unauthorized restoration of earlier authority.
A representative protected state record comprises:
workload_id;
vm_identity;
tenant_id;
authorization_epoch;
capability_id;
candidate_act_digest;
capability_status;
remaining_uses;
last_consumed_nonce;
protected_state_version;
hardware_freshness_reference;
revocation_epoch;
last_committed_validation_reference.
The authoritative state may reside within a protected external
service, HSM-controlled state store, secure monotonic counter,
hardware-backed protected controller, or another mechanism outside
the rollback-accessible snapshot domain.
Das Expires 19 April 2027 [Page 723]
Internet-Draft Protected AI Execution Finality October 2026
The selected implementation must ensure that restoring guest memory
does not roll back the authoritative state required for capability
verification.
Merely placing the state in an ordinary file outside the VM is
insufficient if the relevant attacker can restore that file together
with the guest snapshot.
11.17.31. WF-17.31 — Capability Consumption Before and During
Effectuation
Where the capability is single-use or otherwise usage-bounded, the
system coordinates its required consumption with the protected
Finality Sink operation.
An illustrative capability-state progression is:
AVAILABLE → RESERVED → EFFECTUATION_ATTEMPTED → CONSUMED.
Additional states may include:
DENIED;
REVOKED;
EXPIRED;
INDETERMINATE.
Before effectuation, the Finality Sink verifies that the capability
remains within the permitted usage state.
The protected mechanism prevents an incompatible second operation
from independently consuming the same restricted grant.
Where the external effect cannot be atomically completed together
with local capability consumption, the system preserves the
distinction between reservation, attempted effectuation, and
confirmed completion.
A protected capability reservation does not itself prove that the
remote consequential operation completed.
11.17.32. WF-17.32 — Virtual-Machine Snapshot Restoration
When CV-1701 is restored from an earlier snapshot, RC-1717 performs
the required protected recovery checks.
Das Expires 19 April 2027 [Page 724]
Internet-Draft Protected AI Execution Finality October 2026
The procedure may comprise:
(a) identifying the restored VM;
(b) authenticating the workload identity;
(c) obtaining a current runtime measurement;
(d) verifying the required approved ALF condition;
(e) consulting current protected policy state;
(f) verifying revocation state;
(g) obtaining the authoritative capability-consumption state;
(h) checking nonce or hardware-freshness continuity;
(i) identifying pending or previously attempted Candidate Acts; and
(j) requiring renewed authorization where applicable.
The restored workload cannot independently treat a locally restored
capability as valid.
The applicable Finality Sink verifies the current protected state
rather than trusting the snapshot's prior view of authorization.
11.17.33. WF-17.33 — Snapshot-Replay Rejection
Consider a capability authorizing one protected database
modification.
The capability is consumed during a successful effectuation attempt.
The AI workload is subsequently restored to a snapshot created before
consumption.
The restored VM contains an earlier copy of the capability and may
locally represent it as unused.
However, RS-1715 retains the authoritative consumed state outside the
rollback-accessible guest snapshot.
When the workload attempts to reuse the capability, FS-1713 checks
the current protected consumption record.
The capability is already consumed.
Das Expires 19 April 2027 [Page 725]
Internet-Draft Protected AI Execution Finality October 2026
The repeated operation is refused.
The restored guest's local state does not override the protected
authority state.
11.17.34. WF-17.34 — VM Migration and Workload Replacement
The architecture may also govern migration of an AI workload between
physical hosts or virtualized execution environments.
Where migration changes a mandatory measured execution condition,
workload identity, protected platform generation, or Finality Sink
relationship, the receiving environment must satisfy the applicable
authority requirements before further governed effectuation.
The recovery procedure may verify:
(a) destination host or VM identity;
(b) applicable attestation;
(c) current policy epoch;
(d) protected revocation state;
(e) workload authorization scope;
(f) nonce continuity;
(g) capability-consumption state; and
(h) designated Finality Sink.
A migrated workload does not automatically acquire renewed execution
authority because the migration controller reports successful
restoration.
Where the existing capability remains valid under its expressly
permitted scope and current protected conditions, it may be accepted
according to those conditions.
Where a mandatory binding changes incompatibly, renewed authorization
is required.
11.17.35. WF-17.35 — Revocation and Policy-Epoch Changes
The protected authority may revoke or modify permissions applicable
to the confidential workload.
Das Expires 19 April 2027 [Page 726]
Internet-Draft Protected AI Execution Finality October 2026
Such events may include:
(a) model approval revocation;
(b) tenant authorization withdrawal;
(c) credential-scope change;
(d) invalid runtime attestation;
(e) updated execution policy;
(f) revoked destination service;
(g) compromised workload identity;
(h) modified approved ALF; or
(i) superseded protected policy epoch.
PED-1708 updates or consults the required protected authorization
state.
Where current non-revocation or epoch verification is mandatory, an
affected capability associated with incompatible earlier state is
rejected.
A VM snapshot does not restore authority invalidated by subsequent
protected revocation.
The Finality Sink enforces the required current-state conditions
before the governed operation.
11.17.36. WF-17.36 — Time-of-Check and Time-of-Use Protection
The architecture prevents unauthorized substitution between protected
validation and actual effectuation.
Potential substitutions include:
(a) changing the destination service;
(b) replacing the tenant context;
(c) modifying the operation payload;
(d) changing credential scope;
Das Expires 19 April 2027 [Page 727]
Internet-Draft Protected AI Execution Finality October 2026
(e) substituting a runtime model configuration;
(f) changing an authorized tool workflow;
(g) replacing the applicable VM identity;
(h) using a capability under a different policy epoch;
(i) restoring an earlier nonce; or
(j) reusing consumed authorization after snapshot rollback.
The Finality Sink reconstructs or verifies the effectuation-relevant
actual operation.
Where exact descriptor correspondence is required, a materially
changed mandatory parameter causes verification failure.
Where bounded variations are expressly authorized, the applicable
bounded-scope predicates are enforced.
An earlier attestation or allow decision does not eliminate this
required operation-specific verification.
11.17.37. WF-17.37 — Illustrative Confidential AI-Agent API Operation
In one concrete implementation, an AI agent executes inside a
confidential virtual machine and proposes updating an enterprise
record through an external API.
The confidential VM provides an authenticated workload measurement.
The agent prepares an HTTPS request.
The request is intercepted by IM-1705 before the governed network
effect.
HQ-1706 maintains the operation in a Non-Effective State.
HM-1703 obtains the required virtual-machine and runtime
measurements.
ALF-1704 verifies the applicable approved model and workflow
configuration.
Das Expires 19 April 2027 [Page 728]
Internet-Draft Protected AI Execution Finality October 2026
DC-1707 constructs a Candidate Act Descriptor containing the VM
identity, workload identity, tenant, destination service, operation
class, resource identifier, request-body digest, policy epoch, and
designated Finality Sink.
PED-1708 authenticates the Authority Object.
The PED validates the measured runtime context, approved ALF
condition, permitted tenant, destination, operation, purpose, policy,
revocation, and freshness conditions.
Following successful validation, the protected system performs the
required state transition and commits the corresponding validation
evidence.
CR-1712 releases a scoped non-bearer execution capability.
The network Finality Sink reconstructs or verifies the actual
request.
The Finality Sink checks capability authenticity, operation
correspondence, tenant scope, destination identity, required
protected state, freshness, and validation-evidence commitment.
If the checks succeed, the network interface permits the authorized
request.
If the destination changes or the current runtime configuration fails
a mandatory condition, the operation is refused despite successful
initial confidential VM attestation.
11.17.38. WF-17.38 — Illustrative Composite ALF Mismatch
An AI workload launches within an approved confidential VM.
The hardware attestation report verifies the expected virtual-machine
measurement.
The application then loads a model adapter whose digest differs from
the adapter specified by the approved Composite ALF.
The agent generates a consequential API operation.
PED-1708 obtains or verifies the actual runtime-used adapter
measurement.
The adapter fails the mandatory approved ALF condition.
Das Expires 19 April 2027 [Page 729]
Internet-Draft Protected AI Execution Finality October 2026
The PED withholds the required execution capability.
The Finality Sink refuses the consequential operation.
The initial VM attestation remains valid for the properties it
actually measured, but does not override the failed runtime
configuration condition.
11.17.39. WF-17.39 — Illustrative Cross-Tenant Destination Substitution
An AI workload belonging to Tenant A obtains valid operation-specific
authority to invoke a service belonging to Tenant A.
The corresponding capability is bound to the tenant, workload,
destination service, operation scope, and Finality Sink.
The workload attempts to reuse the capability for a resource
associated with Tenant B.
The Finality Sink identifies the actual receiving tenant or resource
context through its authenticated effectuation interface.
The required tenant binding does not match.
The operation is refused.
Possession of a valid confidential VM attestation does not authorize
access outside the permitted tenant scope.
11.17.40. WF-17.40 — Illustrative Snapshot-Rollback Attack
A confidential VM receives authorization to perform one protected
storage operation.
The PED issues an operation-specific capability under a valid
protected grant.
The storage Finality Sink verifies and consumes the capability.
The VM is later restored from a previously captured snapshot
containing an earlier capability reference.
The workload attempts to repeat the storage operation.
The Finality Sink consults the authoritative capability-consumption
state maintained outside the rollback-accessible VM snapshot.
The capability is already consumed.
Das Expires 19 April 2027 [Page 730]
Internet-Draft Protected AI Execution Finality October 2026
The attempted replay is denied.
The restored snapshot does not regenerate the previously consumed
execution authority.
11.17.41. WF-17.41 — Illustrative Privacy-Preserving Validation
An enterprise AI workload must satisfy a confidential internal
authorization policy before transferring protected data to an
approved service.
The Protected Enforcement Domain validates the required confidential
predicates.
The policy details need not be supplied directly to the external-
facing Finality Sink when the applicable proof or authenticated
validation record permits verification without their disclosure.
The PED commits the protected validation evidence and releases the
scoped execution capability.
The Finality Sink verifies the evidence and capability against the
actual operation, protected authorization scope, destination, and
required current state.
If an actual zero-knowledge construction is employed, the verifier
may validate predicate satisfaction without learning the specified
protected witness information.
If ordinary authenticated evidence is used, the system claims only
the confidentiality properties actually provided by that evidence
mechanism.
The receiving Finality Sink does not treat proof possession as
unrestricted authority for unrelated operations.
11.17.42. WF-17.42 — Failure, Crash, and Recovery Handling
The workflow distinguishes failures occurring at different
authorization and effectuation stages.
Failure before measurement verification: The affected operation
remains non-effective when required runtime measurement cannot be
authenticated.
Failure after valid attestation but before operation authorization:
No valid execution capability becomes available without successful
Candidate Act-specific validation.
Das Expires 19 April 2027 [Page 731]
Internet-Draft Protected AI Execution Finality October 2026
Failure before required evidence commitment: The capability remains
unavailable.
Failure after protected commitment but before capability delivery:
The protected system reconciles committed authorization state before
recovery.
Failure after capability availability but before effectuation: The
Finality Sink verifies current policy, revocation, nonce, scope, and
usage state.
Failure after possible external effectuation: The protected outcome
store distinguishes confirmed completion, known failure, and
indeterminate completion.
VM restart: The restored workload must satisfy any mandatory fresh
attestation and state-continuity requirements.
Snapshot restoration: Previously consumed or revoked authority is not
restored by guest-state rollback.
An indeterminate external effect is not automatically repeated where
an unauthorized duplicate consequence could result.
Where supported, authenticated operation identifiers, downstream
idempotency records, transaction-status queries, or protected
completion receipts may support reconciliation.
The architecture does not assert unconditional exactly-once
completion across arbitrary remote services.
11.17.43. WF-17.43 — Alternative Technical Implementations
The protected confidential-workload finality architecture may be
implemented through several technical arrangements.
Confidential-VM implementation: An AI workload runs within a
hardware-protected confidential virtual machine while operation-
specific authority is established through a suitably protected PED
and Finality Sink.
Hypervisor-mediated implementation: A hypervisor-controlled interface
intercepts governed operations and enforces mandatory capability-
dependent effectuation.
Protected host-service implementation: A host-side protected
authority service validates measured guest context and releases
bounded execution capabilities to a controlled host interface.
Das Expires 19 April 2027 [Page 732]
Internet-Draft Protected AI Execution Finality October 2026
Secure-enclave implementation: Required authorization predicates,
protected state, or cryptographic operations are performed within a
secure enclave or another trusted execution environment.
Service-mesh implementation: A cloud proxy or gateway verifies the
operation-specific capability before permitting protected service
communication.
Credential-broker implementation: Protected credential application
depends upon successful capability verification for the concrete
operation.
Storage-controller implementation: A storage Finality Sink verifies
the applicable capability before persistent mutation.
Hardware-assisted implementation: A SmartNIC, DPU, protected network
controller, or another hardware-controlled interface enforces the
required effectuation condition.
Single-node implementation: Confidential computation, protected
authorization, and local Finality Sink verification operate within
one node while retaining the required functional distinctions.
Distributed implementation: The AI workload, protected authorization
service, and effectuation Finality Sink operate on separately
authenticated computing nodes.
Rollback-resistant implementation: Authoritative nonce, consumption,
or hardware-freshness state is maintained outside the guest snapshot
domain.
Different implementations may provide different guarantees against
privileged host compromise, hypervisor compromise, firmware attacks,
physical attacks, rollback, or side-channel leakage.
The specified properties must be demonstrated within the specified
implementation's threat model.
11.17.44. WF-17.44 — Failure and Fail-Closed Conditions
The protected Finality Sink refuses the governed operation when a
mandatory condition is absent, invalid, expired, revoked,
inconsistent, replayed, or unverifiable.
Non-limiting denial conditions include:
(a) missing runtime measurement;
Das Expires 19 April 2027 [Page 733]
Internet-Draft Protected AI Execution Finality October 2026
(b) invalid VM attestation;
(c) unauthorized VM identity;
(d) workload identity mismatch;
(e) unapproved model identifier;
(f) checkpoint hash mismatch;
(g) adapter hash mismatch;
(h) invalid tokenizer or decoder configuration where required;
(i) unauthorized system-instruction policy;
(j) safety-configuration mismatch;
(k) tool-permission graph mismatch;
(l) retrieval-source graph mismatch;
(m) orchestration graph mismatch;
(n) invalid Composite ALF condition;
(o) failed runtime-used configuration verification;
(p) unauthorized tenant;
(q) destination service mismatch;
(r) invalid destination network context;
(s) unauthorized operation class;
(t) failed Authority Object validation;
(u) stale policy epoch;
(v) invalid revocation state;
(w) failed protected-state transition;
(x) failed required validation-evidence commitment;
(y) invalid privacy-preserving proof where mandatory;
Das Expires 19 April 2027 [Page 734]
Internet-Draft Protected AI Execution Finality October 2026
(z) missing scoped execution capability;
(aa) invalid capability authentication;
(ab) expired nonce;
(ac) consumed or replayed capability;
(ad) incompatible snapshot-restored state;
(ae) hardware-freshness mismatch;
(af) Finality Sink identity mismatch; or
(ag) failure of required non-bypassable enforcement.
The affected Candidate Act remains non-effective, denied,
quarantined, or subject to an authorized recovery procedure.
Failure of confidential-computing attestation does not authorize
fallback to unrestricted ordinary VM execution for the same governed
act.
11.17.45. WF-17.45 — PHOSITA Verification and Negative Tests
A person having ordinary skill in confidential computing, virtual-
machine security, hardware attestation, AI-model infrastructure,
protected authorization, cloud security, cryptography, or distributed
systems may test the architecture through the following cases.
Test 1 — Authorized confidential workload: Run an approved AI
workload with valid measured context and operation-specific
authorization. The Finality Sink permits the scoped operation.
Test 2 — Attestation without capability: Provide valid confidential
VM attestation but no operation-specific capability. Effectuation is
refused.
Test 3 — Invalid VM measurement: Present a VM whose mandatory
measurement differs from the approved condition. Protected
validation fails.
Test 4 — Wrong workload identity: Attempt an operation through a
different workload. Required identity verification fails.
Test 5 — Checkpoint substitution: Replace a mandatory approved
checkpoint with another checkpoint. The Composite ALF condition
fails.
Das Expires 19 April 2027 [Page 735]
Internet-Draft Protected AI Execution Finality October 2026
Test 6 — Adapter substitution: Change the runtime adapter digest
after authorization. The relevant measurement correspondence fails.
Test 7 — Tool-policy widening: Expand the agent's permitted tools
outside the approved policy. Required ALF validation fails.
Test 8 — Retrieval graph modification: Replace an approved retrieval-
source graph. Required logic validation fails.
Test 9 — Orchestration graph mismatch: Modify a mandatory workflow
dependency. Protected authorization refuses the affected Candidate
Act.
Test 10 — Safety-policy change: Substitute an unauthorized safety
configuration. The required approved configuration predicate fails.
Test 11 — Runtime change after launch attestation: Successfully
attest VM launch, then alter a required runtime-used configuration.
The changed context is rejected.
Test 12 — Missing capability: Attempt a consequential operation
without its scoped execution capability. The Finality Sink refuses
it.
Test 13 — Operation substitution: Authorize one API operation and
present materially different required parameters at the Finality
Sink. Verification fails.
Test 14 — Tenant substitution: Present a Tenant A capability for a
Tenant B resource. The tenant-binding check fails.
Test 15 — Destination substitution: Change the actual destination
service or network context. Required destination verification fails.
Test 16 — Policy revocation: Revoke a mandatory authority condition.
Subsequent affected effectuation is denied.
Test 17 — Expired capability: Present the capability outside its
validity interval. Verification fails.
Test 18 — Capability replay: Reuse a consumed single-use capability.
Protected usage verification refuses the operation.
Test 19 — Concurrent consumption: Submit competing operations against
one restricted grant. The protected state mechanism prevents
unauthorized double consumption.
Das Expires 19 April 2027 [Page 736]
Internet-Draft Protected AI Execution Finality October 2026
Test 20 — Snapshot rollback: Restore a VM snapshot containing an
earlier unused-looking capability. The authoritative consumed state
prevents replay.
Test 21 — Nonce rollback: Restore a guest snapshot containing an
earlier nonce. Current protected nonce state rejects unauthorized
reuse.
Test 22 — Protected-state rollback attempt: Attempt to roll back the
authoritative capability store. Verify that the selected protected
implementation detects or prevents the attack within its stated
threat model.
Test 23 — Hardware freshness: Bind a capability to a protected
hardware generation, change that generation, and verify rejection
when the earlier state is incompatible.
Test 24 — Privacy-preserving receipt: Validate the required
authenticated compliance evidence without exposing the protected
predicate inputs specified by the selected mechanism.
Test 25 — Invalid ZK proof: Present an invalid required zero-
knowledge proof. Verification fails.
Test 26 — Valid proof, wrong operation: Present valid evidence
associated with another Candidate Act. The Finality Sink rejects the
mismatched capability or descriptor.
Test 27 — VM migration: Move a workload to another execution
environment and verify that mandatory attestation, policy, and
protected-state continuity conditions remain enforced.
Test 28 — Restart after revocation: Restart or restore the workload
after revocation. The prior authorization remains invalid.
Test 29 — Credential access separation: Verify that confidentiality
of the VM does not by itself permit unrestricted use of protected
connector credentials.
Test 30 — Network bypass: Attempt the same governed effect through an
alternative network path. The operation remains mediated or blocked.
Test 31 — Single-node implementation: Integrate protected authority
and Finality Sink functions within one node and verify that the
required authorization and actual-operation checks remain
enforceable.
Das Expires 19 April 2027 [Page 737]
Internet-Draft Protected AI Execution Finality October 2026
Test 32 — Distributed implementation: Issue a capability through a
protected authority service and verify it at a separate cloud
Finality Sink. Incompatible operation, state, or identity bindings
are rejected.
Test 33 — Crash before evidence commitment: Interrupt the required
protected finality transaction. No valid corresponding capability
becomes available.
Test 34 — Crash after possible remote effect: Interrupt communication
after a downstream operation may have completed. Recovery preserves
accurate confirmed or indeterminate outcome state.
Test 35 — Confidentiality versus authority: Demonstrate that an
attested confidential workload may compute successfully while an
unauthorized Candidate Act remains blocked.
The tests may employ confidential-VM development environments,
virtualized attestation test fixtures, controlled AI model
configurations, authenticated authority stores, protected capability
services, mock Finality Sinks, snapshot-and-restore facilities,
rollback fault injection, and simulated cloud destination services.
The observed security guarantees depend upon the implementation's
actual trust roots, enforcement coverage, and failure assumptions.
11.17.46. WF-17.46 — Claim-Specific Technical Support
Enforcement Point 73 — Protected Confidential-VM AI-Execution
Finality
The workflow describes:
(a) CV-1701 providing a confidential or isolated VM execution
environment;
(b) AE-1702 generating consequential operations;
(c) HM-1703 producing machine-verifiable execution-context
measurement or attestation;
(d) IM-1705 intercepting a Candidate Act before a governed
effectuation boundary;
(e) HQ-1706 maintaining the Candidate Act in a Non-Effective State;
(f) PED-1708 validating the execution context against an Approved ALF
Condition or protected runtime-authority condition;
Das Expires 19 April 2027 [Page 738]
Internet-Draft Protected AI Execution Finality October 2026
(g) protected validation of the Candidate Act against authority,
purpose, scope, policy, revocation, and freshness requirements;
(h) EV-1711 generating or committing the applicable validation
evidence;
(i) CR-1712 releasing the scoped, non-bearer execution capability;
and
(j) FS-1713 independently verifying the capability before
effectuation.
The workflow expressly distinguishes successful confidential-VM
attestation from Candidate Act-specific execution authority.
Enforcement Point 74 — Hardware-Rooted Composite ALF
WF-17.8 through WF-17.10 describe the Composite ALF incorporating the
specified model, checkpoint, adapter, tokenizer, decoder, instruction
policy, safety configuration, tool graph, retrieval graph,
orchestration graph, VM measurement, attestation, and policy-epoch
attributes.
Enforcement Point 75 — Measured Workload Configuration
WF-17.11 and WF-17.12 describe comparison of actual runtime-used
model, workflow, tool, and policy configuration against approved
measurements, including denial despite successful initial VM
authentication.
Enforcement Point 76 — Privacy-Preserving Cryptographic Validation
WF-17.23 and WF-17.24 describe authenticated validation receipts or
applicable zero-knowledge evidence enabling verification of protected
authority and runtime-integrity predicates without requiring
disclosure of specified confidential internal information.
Enforcement Point 77 — Cloud Tenant and Destination Scope
WF-17.27 and WF-17.28 describe binding the Candidate Act Descriptor
and capability to tenant, workload, VM, destination service,
destination network context, and policy epoch, preventing
unauthorized cross-tenant or destination reuse.
Enforcement Point 78 — Virtual-Machine Snapshot Replay Resistance
Das Expires 19 April 2027 [Page 739]
Internet-Draft Protected AI Execution Finality October 2026
WF-17.29 through WF-17.33 describe maintaining authoritative
protected capability-consumption, nonce, or hardware-freshness state
outside the workload's rollback-accessible snapshot domain and
rejecting previously consumed, revoked, or invalidated execution
authority after restoration.
11.17.47. WF-17.47 — Technical Effect
The disclosed workflow establishes a protected dependency between:
(a) execution of an AI workload inside a confidential or isolated
virtual machine;
(b) machine-verifiable measurement of the actual required execution
context;
(c) verification of an Approved Algorithmic Logic Fingerprint
Condition;
(d) generation of a consequential Candidate Act;
(e) interception and maintenance in a Non-Effective State;
(f) construction of an effectuation-relevant Candidate Act
Descriptor;
(g) protected validation of authority, purpose, runtime
configuration, tenant, destination, policy, revocation, and
freshness;
(h) required protected-state handling;
(i) protected validation-evidence commitment;
(j) scoped, non-bearer execution-capability availability;
(k) independent Finality Sink verification against the actual
operation;
(l) controlled effectuation or fail-closed withholding; and
(m) preservation of protected authorization and capability-
consumption state across snapshot rollback or recovery.
The confidential-computing environment protects specified computation
properties but does not independently supply unlimited authority over
effect-capable cloud, host, network, service, credential, or storage
interfaces.
Das Expires 19 April 2027 [Page 740]
Internet-Draft Protected AI Execution Finality October 2026
The Composite ALF embodiment binds authorization to the measured
model and workflow configuration actually required for the operation.
The privacy-preserving variant supports validation without
unnecessarily exposing designated protected information, according to
the actual cryptographic mechanism.
The tenant-bound capability variant prevents cross-tenant or
destination substitution outside the authorized scope.
The snapshot-resistance variant prevents restoration of guest state
from reviving execution authority already consumed, revoked, or
invalidated in the authoritative protected state.
Computation is not authority to act.
Confidential execution is not authorization for an external
operation.
Hardware attestation is not a substitute for Candidate Act-specific
authority.
A valid capability for one tenant is not authority for another
tenant.
Restoring a VM snapshot must not restore previously consumed
execution authority.
11.18. WF-18 — Confidential Governance Virtual Machine, Hardware-Rooted
Attestation, Protected Governance-Key Isolation, Authenticated
Fabric Capability Delivery, and Hardware-Enforced SmartNIC
Finality
11.18.1. WF-18.1 — Technical Purpose
This embodiment describes a hardware-assisted system for governing
externally effective operations and transfers generated within
artificial-intelligence compute infrastructure.
The system comprises an AI compute node, a governance compute node
operating within a confidential virtual-machine environment, a
hardware-rooted attestation mechanism, a Protected Enforcement Domain
(PED), an operation-specific authorization component, an
authenticated fabric-management communication path, and a hardware-
enforced Finality Sink associated with a SmartNIC, data processing
unit, rack-boundary controller, accelerator-egress interface, or
protected network-forwarding component.
Das Expires 19 April 2027 [Page 741]
Internet-Draft Protected AI Execution Finality October 2026
The governance compute node operates under hardware-supported memory
confidentiality or integrity protection.
Its authenticated attestation record identifies the governance
workload measurement and protected execution configuration.
The PED verifies the record against an approved hardware trust root,
registered governance identity, and applicable protected policy
state.
An AI compute node may generate or prepare an external operation, but
does not thereby acquire permission to transmit or effectuate the
operation.
The proposed operation is classified as a Candidate Act and remains
non-effective at the governed boundary until the PED validates the
required act-specific authority and makes available a scoped
execution capability.
The scoped capability is delivered through an authenticated fabric-
management communication path toward the effectuation controller.
The hardware-enforced Finality Sink verifies the capability against:
(a) the Candidate Act;
(b) the authorized effectuation boundary;
(c) the registered attestation state of the issuing governance
component; and
(d) other mandatory authorization, freshness, scope, and protected-
state conditions.
When a required attestation state becomes invalid or capability
verification fails, the hardware-enforced Finality Sink prevents the
proposed operation from crossing the governed external-transmission
boundary.
The architecture distinguishes confidential governance execution, the
authority to issue capabilities, transport of capability material,
and independent hardware enforcement of a specific external effect.
11.18.2. WF-18.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises the following
components.
Das Expires 19 April 2027 [Page 742]
Internet-Draft Protected AI Execution Finality October 2026
AI-1801 — Artificial-Intelligence Compute Node
An AI agent, model-serving node, GPU server, accelerator workload,
orchestration service, or other computational environment configured
to produce a proposed external operation or transfer.
GC-1802 — Confidential Governance Compute Node
A governance compute node executing within a confidential virtual-
machine environment and providing hardware-supported memory
confidentiality or integrity protection.
HA-1803 — Hardware-Rooted Attestation Component
A component configured to generate an authenticated record
identifying the governance workload measurement and protected
execution configuration.
AT-1804 — Hardware Finality Gate Attestation Object
An authenticated representation of the governance-node state,
optionally including firmware digest, confidential-VM policy version,
launch measurement, host-data field, hardware signing evidence, and
protected device identity.
TR-1805 — Registered Hardware Trust-Root Store
A protected or authenticated trust store containing approved
hardware-vendor certificate authorities, registered public keys,
governance identities, approved measurements, and applicable trust
restrictions.
PED-1806 — Protected Enforcement Domain
A protected authorization component configured to verify governance-
node attestation and perform Candidate Act-specific authorization.
AS-1807 — Protected Governance Authority Store
A component maintaining registered governance identities, Authority
Objects, authorized effectuation boundaries, policy epochs,
revocation state, and applicable issuance conditions.
KS-1808 — Protected Governance-Key Component
A protected mechanism maintaining cryptographic governance or
capability-issuance key material outside the unrestricted access of
ordinary AI compute processes.
Das Expires 19 April 2027 [Page 743]
Internet-Draft Protected AI Execution Finality October 2026
IM-1809 — Candidate Act Interception Component
An enforcement-controlled interface configured to identify and hold a
proposed external operation before a governed effectuation boundary.
HQ-1810 — Non-Effective Candidate Act Holding Mechanism
A controlled queue, transfer buffer, inactive forwarding entry,
pending request, blocked DMA descriptor, or equivalent mechanism
retaining the Candidate Act pending authorization.
DC-1811 — Candidate Act Descriptor Component
A component configured to construct or verify the machine-readable
representation of the proposed external operation.
PS-1812 — Protected Authorization-State Store
A component maintaining nonce state, policy epochs, revocation state,
capability usage, attestation generation, and required protected
commitments.
EV-1813 — Validation-Evidence Component
A mechanism configured to generate or commit a protected validation
record or authenticated authorization commitment where required by
the selected DAS finality embodiment.
CR-1814 — Operation-Scoped Capability Component
A protected mechanism configured to generate, register, derive,
release, or activate the execution capability required for the
Candidate Act.
FM-1815 — Authenticated Fabric-Management Communication Path
A protected or authenticated interface configured to convey the
execution capability or corresponding protected capability state from
the governance node or protected authority component toward the
hardware effectuation controller.
HC-1816 — Hardware Effectuation Controller
A SmartNIC, DPU, rack-boundary network controller, accelerator-egress
controller, or other hardware-associated network-enforcement
component.
FS-1817 — Hardware-Enforced Finality Sink
Das Expires 19 April 2027 [Page 744]
Internet-Draft Protected AI Execution Finality October 2026
The actual governed network-transmission, forwarding, accelerator-
egress, or other effectuation interface configured to verify
capability authority before enabling the corresponding external
operation.
HF-1818 — Protected Hardware-Freshness Component
A mechanism maintaining trusted counters, secure boot epochs,
protected clock references, device sequences, hardware-attested
nonces, or equivalent freshness state.
RV-1819 — Attestation Revocation and Revalidation Component
A mechanism configured to invalidate unacceptable governance-node
attestation state and withhold affected capability issuance or
effectuation.
OS-1820 — Protected Effectuation-Outcome Store
A mechanism maintaining pending, reserved, denied, transmitted,
revoked, indeterminate, and other relevant operation-outcome states.
RC-1821 — Recovery and State-Reconciliation Component
A component configured to restore valid protected governance
operation after an authorized attestation, infrastructure, or
hardware recovery procedure.
The components may operate on separate physical devices or be
integrated within one protected server or network-controller
arrangement.
The architectural roles of governance authority, capability delivery,
and hardware effectuation verification remain distinguishable.
11.18.3. WF-18.3 — Establishment of the AI Compute-to-Governance Trust
Boundary
AI-1801 is configured as a computational environment rather than the
exclusive source of protected execution authority.
It may perform inference, generate tool instructions, prepare network
packets, produce accelerator outputs, or construct consequential
requests.
However, it does not independently control the key material,
protected authorization state, or registered governance attestation
required for effectuation.
Das Expires 19 April 2027 [Page 745]
Internet-Draft Protected AI Execution Finality October 2026
An authenticated interface connects the AI compute environment to the
protected governance architecture.
The interface may accept proposed Candidate Act information and
return an authorization status or protected capability reference.
It does not expose unrestricted governance private keys or permit the
AI workload to write protected authorization records.
A compromised or untrusted ordinary AI process therefore cannot
create a valid execution capability merely by modifying the request
it sends to the governance node.
The exact protection depends upon the isolation provided by the
selected confidential-computing and key-management implementation.
11.18.4. WF-18.4 — Establishment of the Confidential Governance VM
GC-1802 operates within a confidential virtual-machine environment.
The environment may provide:
(a) hardware-supported guest-memory confidentiality;
(b) protected execution-state integrity;
(c) measured launch;
(d) isolated governance software;
(e) authenticated platform attestation;
(f) controlled device or host access;
(g) protected governance configuration; and
(h) access to cryptographic key operations subject to the applicable
trust boundary.
The actual protections are determined by the confidential VM's
hardware and software architecture.
A confidential VM is not assumed to protect against every privileged
host, firmware, physical, or side-channel attack.
The critical functional requirement is that the protected governance
identity and issuance state cannot be unilaterally altered by the
ordinary AI compute process under the applicable threat model.
Das Expires 19 April 2027 [Page 746]
Internet-Draft Protected AI Execution Finality October 2026
11.18.5. WF-18.5 — Governance-Node Identity Registration
Before accepting governance-node-issued capabilities, the protected
authority system registers the identities or trust conditions of
permitted governance components.
A non-limiting registration record comprises:
governance_node_id;
confidential_vm_identity;
approved_governance_measurement;
registered_attestation_public_key;
accepted_hardware_trust_root;
authorized_policy_version;
permitted_capability_classes;
permitted_effectuation_sinks;
registration_epoch;
revocation_state.
The registered governance identity may be associated with an approved
hardware certificate chain or registered public-key trust root.
The system distinguishes a governance identity asserted by a
requester from an identity authenticated through the required trust
mechanism.
Registration does not automatically authorize arbitrary execution-
capability issuance.
The governance node remains subject to the applicable Authority
Objects and protected operation-specific conditions.
11.18.6. WF-18.6 — Hardware Finality Gate Attestation Object Formation
in the implementation described by enforcement point 80, HA-1803
produces a Hardware Finality Gate Attestation Object.
The object may include one or more of:
Das Expires 19 April 2027 [Page 747]
Internet-Draft Protected AI Execution Finality October 2026
(a) governance firmware digest;
(b) confidential virtual-machine policy version;
(c) confidential-VM launch measurement;
(d) host-data field;
(e) hardware signing evidence; and
(f) protected device identity.
A non-limiting representation comprises:
attestation_object_id;
governance_node_id;
protected_device_identity;
governance_firmware_digest;
vm_launch_measurement;
vm_policy_version;
host_data;
measurement_generation;
attestation_nonce;
hardware_signing_evidence;
certificate_chain_reference.
The object identifies specified measured or authenticated properties
of the governance environment.
Fields not measured or authenticated by the selected attestation
technology must not be treated as established merely because they
appear in a software-created record.
The applicable attestation procedure determines which object fields
are security-relevant and how their provenance is verified.
Das Expires 19 April 2027 [Page 748]
Internet-Draft Protected AI Execution Finality October 2026
11.18.7. WF-18.7 — Hardware Trust-Root Verification
PED-1806 authenticates the governance-node attestation against TR-
1805.
The verification may include:
(a) verification of the attestation signature;
(b) verification of the applicable hardware-vendor certificate chain;
(c) validation against a registered public-key trust root;
(d) confirmation of governance-node identity;
(e) confirmation of the approved governance workload measurement;
(f) confirmation of the required protected execution configuration;
(g) verification of freshness or challenge association; and
(h) confirmation of applicable protected policy and revocation state.
An illustrative predicate is:
AttestationAcceptable =
AuthenticAttestation AND
RegisteredGovernanceIdentity AND
ApprovedMeasurement AND
ValidPolicyState AND
RequiredFreshness
Each term represents a mandatory check only where required by the
selected authorization.
An authentic but unapproved governance-node measurement is not
automatically acceptable.
A previously approved governance-node identity does not override an
invalid required firmware or policy measurement.
Das Expires 19 April 2027 [Page 749]
Internet-Draft Protected AI Execution Finality October 2026
11.18.8. WF-18.8 — Governance Attestation State Registration
Following successful verification, the protected system establishes a
registered attestation-state reference.
A representative record comprises:
governance_node_id;
attestation_object_digest;
approved_measurement_reference;
attestation_generation;
policy_epoch;
attestation_status;
validity_conditions;
registered_public_key_reference;
affected_capability_classes;
authorized_effectuation_sinks.
The attestation state may be maintained by the PED, a protected
governance registry, the hardware effectuation controller, or a
suitable combination.
The hardware Finality Sink must be able to verify the required
registered attestation state associated with the capability issuer.
It is insufficient for the governance VM to assert its own current
validity without the required independent authentication.
11.18.9. WF-18.9 — Protected Governance-Key Isolation
in the implementation described by enforcement point 81, KS-1808
maintains cryptographic key material used for governance or
capability issuance within a protected governance boundary.
Such key material may include:
(a) a private capability-signing key;
(b) a MAC key used to authenticate capabilities;
Das Expires 19 April 2027 [Page 750]
Internet-Draft Protected AI Execution Finality October 2026
(c) a protected governance key-encryption key;
(d) an authenticated fabric-control channel key;
(e) a protected attestation-bound derivation key; or
(f) other cryptographic authority material required by the
implementation.
The ordinary AI compute process cannot read or export unrestricted
governance keys.
The compute node communicates with the protected governance component
through an authenticated interface.
The interface may allow submission of a Candidate Act but does not
grant unrestricted access to the protected key itself.
The protected component controls key use according to the required
authority and attestation predicates.
11.18.10. WF-18.10 — Protected Capability Issuance Key Use
A governance key is not merely a cryptographic utility available to
any authenticated compute process.
Where the key is used to generate execution capabilities, key use
remains dependent upon the applicable operation-specific
authorization.
An illustrative protected key-use predicate is:
PermitCapabilityIssue =
AttestationAcceptable AND
GovernanceIdentityValid AND
CandidateActAuthorized AND
ProtectedStateValid
The issuing component refuses the corresponding key operation if a
mandatory predicate fails.
Possession of a signing-service endpoint or key identifier is not
sufficient authority to mint valid execution capabilities.
Das Expires 19 April 2027 [Page 751]
Internet-Draft Protected AI Execution Finality October 2026
A protected key that can issue unrestricted permits without
operation-specific checks would not establish the specified finality
relationship merely because it is held inside a confidential VM.
11.18.11. WF-18.11 — Candidate Act Generation
AI-1801 generates a proposed external operation or transfer.
The operation may comprise:
(a) outbound network transmission;
(b) API invocation;
(c) inter-node data transfer;
(d) accelerator-output export;
(e) model-state transfer;
(f) privileged service call;
(g) authenticated message dispatch; or
(h) another consequential operation crossing the selected hardware-
enforced effectuation boundary.
The proposed operation is classified as Candidate Act CA-1822.
Generation of CA-1822 does not independently authorize its execution.
The required external effect remains subject to protected capability
issuance and hardware Finality Sink verification.
11.18.12. WF-18.12 — Non-Effective Staging
IM-1809 intercepts or controls CA-1822 before the governed external-
transmission effect.
HQ-1810 maintains the Candidate Act in a Non-Effective State.
An illustrative pending operation record comprises:
candidate_act_id;
requesting_compute_node;
operation_class;
Das Expires 19 April 2027 [Page 752]
Internet-Draft Protected AI Execution Finality October 2026
source_interface;
destination_interface;
payload_reference;
requested_effectuation_boundary;
policy_epoch;
governance_attestation_reference;
status = NON_EFFECTIVE.
The proposed operation may be retained in a queue, protected buffer,
inactive forwarding descriptor, or another controlled representation.
The applicable hardware enforcement mechanism prevents the operation
from becoming effective merely because the AI workload submitted it.
Where the hardware controller would otherwise accept an unrestricted
alternate path, the implementation must restrict or equivalently
govern that path to establish the specified non-bypassable behavior.
11.18.13. WF-18.13 — Candidate Act Descriptor Formation
DC-1811 constructs or verifies the Candidate Act Descriptor.
The descriptor may identify:
candidate_act_id;
requesting_compute_node_id;
workload_identity;
operation_class;
source_interface;
destination_service_or_node;
requested_network_destination;
payload_digest;
authorized_effectuation_boundary;
Das Expires 19 April 2027 [Page 753]
Internet-Draft Protected AI Execution Finality October 2026
required_governance_node_id;
attestation_state_reference;
policy_epoch;
revocation_epoch;
nonce;
expiry;
hardware_freshness_reference;
finality_sink_id.
The applicable Authority Object determines which fields are
mandatory.
The descriptor identifies the operation actually being proposed for
external effectuation.
It is distinct from the governance-node attestation record.
11.18.14. WF-18.14 — Canonical Candidate Act Representation
In one illustrative cryptographic implementation:
Dhw = Canon_v(SRC, ACT, DST, PAYLOAD, BOUNDARY, GOV, EPOCH, FRESH,
SINK)
where:
Dhw denotes the canonical hardware-governed Candidate Act Descriptor;
SRC denotes the authenticated source compute context;
ACT denotes the proposed operation;
DST denotes the destination or recipient;
PAYLOAD denotes the effectuation-relevant payload or its
authenticated digest;
BOUNDARY denotes the authorized effectuation boundary;
GOV denotes the issuing governance-node identity and required
attestation-state reference;
Das Expires 19 April 2027 [Page 754]
Internet-Draft Protected AI Execution Finality October 2026
EPOCH denotes applicable protected authorization-state versions;
FRESH denotes required hardware-freshness information; and
SINK denotes the designated hardware Finality Sink.
An illustrative digest is:
hHw = H("DAS-HARDWARE-FINALITY-v1" || Encode(Dhw))
The selected encoding distinguishes mandatory fields and provides
compatible interpretation at the PED and Finality Sink.
The formula represents an optional detailed implementation; the
particular hash algorithm and serialization are not required by the
cited claim language.
11.18.15. WF-18.15 — Candidate Act Authority Validation
PED-1806 obtains the applicable Authority Object from AS-1807.
The authority may specify:
(a) permitted requesting compute nodes;
(b) authorized operation classes;
(c) permitted destinations;
(d) approved payload or data classifications;
(e) protected governance identities;
(f) required governance-node attestation state;
(g) authorized hardware effectuation boundaries;
(h) policy epochs;
(i) revocation conditions;
(j) nonce or usage limits;
(k) required protected authorization-state transitions; and
(l) applicable Finality Sink identities.
Das Expires 19 April 2027 [Page 755]
Internet-Draft Protected AI Execution Finality October 2026
The PED validates the concrete Candidate Act rather than relying
exclusively upon successful governance-node attestation.
An acceptable governance attestation establishes the selected trust
condition for the issuer, but the proposed operation must
independently satisfy its mandatory authority predicates.
11.18.16. WF-18.16 — Combined Attestation and Act-Specific
Authorization Predicate
An illustrative predicate is:
Vhw =
Pgovernance AND
Pattestation AND
Pcandidate AND
Pscope AND
Pboundary AND
Pstate
where:
Vhw denotes the protected authorization result;
Pgovernance verifies the registered governance-node identity;
Pattestation verifies the required acceptable attestation state;
Pcandidate verifies the proposed Candidate Act;
Pscope verifies the authorized operation and destination scope;
Pboundary verifies the designated hardware-controlled effectuation
boundary; and
Pstate verifies policy, revocation, nonce, freshness, and applicable
protected authorization state.
An operation is not authorized merely because Pattestation succeeds.
All mandatory act-specific authorization predicates must also
succeed.
Das Expires 19 April 2027 [Page 756]
Internet-Draft Protected AI Execution Finality October 2026
Where an applicable Authority Object requires an approved threshold
or alternative authorization combination, the PED evaluates that
expressly authorized combination.
11.18.17. WF-18.17 — Protected Authorization-State Handling
Upon successful authorization, PED-1806 performs or verifies the
protected-state operations required for CA-1822.
These may include:
(a) verifying the current governance attestation generation;
(b) verifying policy and revocation epochs;
(c) reserving an operation-specific grant;
(d) registering or consuming a nonce;
(e) allocating a bounded transfer allowance;
(f) registering the required hardware-freshness state;
(g) recording the Candidate Act Descriptor commitment;
(h) registering an authorized effectuation boundary; or
(i) another required protected authorization transition.
Where authorization is single-use, protected state prevents
unauthorized duplicate consumption.
Where a transfer is explicitly usage-bounded, the applicable
protected counters or hardware-enforced limits govern permitted
usage.
A failed mandatory state transition prevents corresponding capability
issuance.
11.18.18. WF-18.18 — Protected Validation Evidence
In a selected DAS embodiment requiring protected validation-evidence
commitment, EV-1813 generates or commits the corresponding evidence.
An illustrative record comprises:
receipt_id;
Das Expires 19 April 2027 [Page 757]
Internet-Draft Protected AI Execution Finality October 2026
candidate_act_id;
descriptor_digest;
governance_node_id;
attestation_state_reference;
authority_object_reference;
policy_epoch;
protected_state_transition;
nonce;
hardware_freshness_reference;
finality_sink_id;
validation_result;
protected_authentication.
The evidence may comprise an AVR, LAVR, sealed record, authenticated
commitment, or another supported protected artifact.
Where evidence commitment is a required precondition to capability
availability, the protected system completes the commitment before,
or atomically with, release of the scoped capability.
The exact text of enforcement point 79 does not independently
prescribe every LAVR or evidence-commitment detail included in this
fuller workflow; those additional dependencies apply to embodiments
that expressly require them.
11.18.19. WF-18.19 — Scoped Execution-Capability Generation
Following successful protected authorization, CR-1814 releases or
makes available an operation-scoped execution capability.
The capability contains or securely references:
capability_id;
candidate_act_digest;
issuing_governance_identity;
Das Expires 19 April 2027 [Page 758]
Internet-Draft Protected AI Execution Finality October 2026
governance_attestation_state_reference;
authorized_operation;
authorized_destination;
authorized_effectuation_boundary;
policy_epoch;
revocation_epoch;
nonce;
expiry;
hardware_freshness_reference;
usage_limit;
finality_sink_id.
Where a receipt dependency is required, the capability additionally
incorporates or references the corresponding committed protected
validation evidence.
The capability is not an unrestricted permission for the issuing
governance VM to transmit any data.
Its validity depends upon the authorized operation, effectuation
boundary, applicable registered attestation state, and other
mandatory protected conditions.
11.18.20. WF-18.20 — Cryptographically Authenticated Capability
A non-limiting capability representation is:
Chw = Sign_skGOV(Encode(hHw, GovID, AttestRef, Scope, Boundary,
Epoch, Fresh, Nonce, Expiry, Sink))
where:
Chw denotes the execution capability;
Sign_skGOV denotes signing under protected governance key material;
hHw denotes the Candidate Act Descriptor digest;
Das Expires 19 April 2027 [Page 759]
Internet-Draft Protected AI Execution Finality October 2026
GovID denotes the registered governance identity;
AttestRef denotes the required governance attestation-state
reference;
Scope denotes permitted operation scope;
Boundary denotes the authorized effectuation boundary;
Epoch denotes applicable protected policy state;
Fresh denotes hardware freshness;
Nonce denotes the required freshness value;
Expiry denotes capability validity; and
Sink denotes the designated hardware Finality Sink.
A MAC-authenticated permit, sealed capability handle, protected
forwarding-table entry, or another supported representation may be
used instead.
The non-bearer character of the capability depends upon actual
verification of its operation, context, state, usage, and sink
restrictions.
11.18.21. WF-18.21 — Authenticated Fabric-Management Capability
Delivery
FM-1815 transfers or makes available the authorized execution
capability from the governance node or protected authority toward HC-
1816.
The communication path may employ:
(a) mutually authenticated management transport;
(b) a protected device-control queue;
(c) an authenticated DPU management interface;
(d) a protected SmartNIC control channel;
(e) authenticated inter-processor messaging;
(f) an HSM-authenticated fabric-control message;
Das Expires 19 April 2027 [Page 760]
Internet-Draft Protected AI Execution Finality October 2026
(g) a sealed capability-table installation command; or
(h) another authenticated management mechanism.
The receiving component verifies the origin and integrity of the
transmitted authorization material.
A successful management-channel connection does not independently
establish that the conveyed capability is valid for the particular
Candidate Act.
The hardware Finality Sink verifies the applicable operation-specific
and attestation-state conditions before effectuation.
11.18.22. WF-18.22 — Capability Delivery and Actual-Operation
Consistency
Where the management plane delivers a capability before the
corresponding data-plane operation arrives, the hardware controller
maintains a protected association between them.
An illustrative installed authorization entry comprises:
capability_id;
candidate_act_digest;
source_node_id;
destination_reference;
authorized_effectuation_boundary;
issuing_governance_node_id;
registered_attestation_generation;
policy_epoch;
freshness_reference;
remaining_uses;
expiry;
status.
Das Expires 19 April 2027 [Page 761]
Internet-Draft Protected AI Execution Finality October 2026
The data-plane operation is admitted only when its effectuation-
relevant attributes satisfy the protected entry.
A capability installed for one destination or operation cannot
automatically authorize a different transfer.
An ordinary management-plane acknowledgement does not itself prove
that the governed data-plane transfer has been completed.
11.18.23. WF-18.23 — Hardware Finality Sink Verification
Before external transmission, FS-1817 independently verifies:
(a) execution-capability authenticity;
(b) the Candidate Act or its required descriptor commitment;
(c) authorized operation and destination scope;
(d) designated hardware-enforced effectuation boundary;
(e) registered identity of the capability issuer;
(f) acceptable attestation state of the governance component;
(g) policy epoch and revocation state where mandatory;
(h) required hardware freshness;
(i) nonce and expiry;
(j) usage or consumption state; and
(k) protected validation-evidence reference where required.
The Finality Sink obtains the actual operation through its controlled
hardware or network interface.
It does not rely solely upon an agent-supplied statement that the
operation has been approved.
A capability from an unregistered or improperly attested governance
node is rejected when the registered governance-state binding is
mandatory.
Das Expires 19 April 2027 [Page 762]
Internet-Draft Protected AI Execution Finality October 2026
11.18.24. WF-18.24 — Hardware Finality Verification Predicate
An illustrative finality predicate is:
PermitHardware =
Auth(C) AND
ActMatch(C,Dactual) AND
IssuerValid(C,Gregistered) AND
AttestationValid(C,Acurrent) AND
BoundaryValid(C,F) AND
StateValid(C,S)
where:
PermitHardware denotes permission to cross the governed hardware
boundary;
C denotes the scoped capability;
Dactual denotes the actual operation descriptor;
Gregistered denotes the registered governance identity;
Acurrent denotes the required current attestation state;
F denotes the designated hardware Finality Sink; and
S denotes applicable protected authorization state.
Auth verifies capability authentication.
ActMatch verifies operation correspondence.
IssuerValid verifies registered governance identity.
AttestationValid verifies the required acceptable governance
attestation state.
BoundaryValid verifies the authorized effectuation interface.
StateValid verifies current policy, revocation, freshness, nonce, and
usage conditions.
Das Expires 19 April 2027 [Page 763]
Internet-Draft Protected AI Execution Finality October 2026
The hardware Finality Sink enables the governed operation only when
every mandatory predicate succeeds.
11.18.25. WF-18.25 — Hardware-Enforced Transmission Interlock
HC-1816 controls an actual external transmission or forwarding
boundary.
The hardware controller may implement the interlock through:
(a) protected transmit queue admission;
(b) a hardware forwarding-table entry;
(c) a protected network-egress enablement bit;
(d) a bounded DMA or descriptor authorization;
(e) a DPU-controlled forwarding pipeline;
(f) a SmartNIC packet admission rule;
(g) an accelerator-egress control; or
(h) another hardware-controlled effectuation interface.
Before required verification succeeds, the selected boundary remains
non-admitting for the Candidate Act.
After successful verification, the controller permits only the
operation authorized by the capability.
The implementation must establish that the hardware controller
actually controls the governed effect.
Merely observing transmission or generating an alert does not satisfy
a requirement to prevent unauthorized external transmission.
11.18.26. WF-18.26 — Confidential Governance Measurement Change
in the implementation described by enforcement point 82, a required
governance-node measurement may change.
Relevant changes include:
(a) governance firmware measurement;
(b) confidential-VM launch measurement;
Das Expires 19 April 2027 [Page 764]
Internet-Draft Protected AI Execution Finality October 2026
(c) protected policy version;
(d) protected software configuration; or
(e) another required approved governance-state attribute.
The attestation system produces or establishes a state that no longer
satisfies the approved governance-node measurement condition.
PED-1806 refuses further capability issuance dependent upon that
governance node until successful revalidation.
The selected implementation also determines whether already issued
capabilities are invalidated at the hardware Finality Sink.
Where enforcement point 79's required registered attestation state
must remain acceptable at effectuation, FS-1817 verifies that
condition before admitting further affected operations.
A refusal to issue new capabilities is not automatically equivalent
to revocation of all previously issued capabilities unless the
corresponding sink-side state checks enforce that result.
11.18.27. WF-18.27 — Attestation Revalidation
Following an authorized governance-node software, firmware, or policy
update, RV-1819 may initiate revalidation.
The procedure may include:
(a) obtaining a fresh authenticated attestation record;
(b) verifying the hardware trust chain;
(c) identifying the governance-node identity;
(d) evaluating the new launch or firmware measurement;
(e) verifying the approved policy configuration;
(f) authenticating required freshness;
(g) establishing current registered attestation state;
(h) updating the corresponding protected generation; and
(i) permitting renewed operation-specific capability issuance only
when required conditions succeed.
Das Expires 19 April 2027 [Page 765]
Internet-Draft Protected AI Execution Finality October 2026
Successful revalidation does not automatically authorize operations
that remain outside their individual Authority Objects.
A changed governance measurement is not automatically unacceptable
forever; it may be accepted after protected approval under the
applicable governance policy.
11.18.28. WF-18.28 — Hardware-Freshness Binding
in the implementation described by enforcement point 83, the
execution capability is additionally bound to hardware-freshness
state.
The state may comprise at least one of:
(a) trusted monotonic counter;
(b) secure boot epoch;
(c) protected clock;
(d) device sequence value; or
(e) hardware-attested nonce.
An illustrative freshness record comprises:
device_id;
governance_node_id;
hardware_boot_epoch;
secure_counter;
device_sequence;
trusted_time_reference;
hardware_nonce;
freshness_generation.
The protected authority binds the applicable freshness information to
the capability.
The hardware Finality Sink verifies the required relationship between
the capability and the current authorized hardware-freshness state.
Das Expires 19 April 2027 [Page 766]
Internet-Draft Protected AI Execution Finality October 2026
A capability referencing incompatible previous state is rejected.
11.18.29. WF-18.29 — Snapshot, Reset, and Hardware Replay Resistance
The system addresses replay of previously valid authorization
material following:
(a) governance VM snapshot restoration;
(b) device reset;
(c) firmware restart;
(d) hardware-controller failover;
(e) protected capability-table restoration;
(f) management-channel replay; or
(g) another restoration of earlier software-visible state.
Where a trusted monotonic counter or secure boot epoch is required,
the current protected value must remain authoritative independently
of rollback-accessible state.
An earlier capability fails when its mandatory freshness binding no
longer corresponds to the protected current state.
A software timestamp alone does not establish strong rollback
resistance where the attacker can restore the corresponding time or
authorization state.
Hardware freshness is verified according to the selected trust model.
11.18.30. WF-18.30 — Capability Consumption and Hardware State
Where a capability is single-use or usage-bounded, HC-1816 performs
or coordinates its protected consumption.
An illustrative state record comprises:
capability_id;
candidate_act_digest;
governance_attestation_generation;
hardware_freshness_reference;
Das Expires 19 April 2027 [Page 767]
Internet-Draft Protected AI Execution Finality October 2026
authorized_effectuation_boundary;
remaining_uses;
remaining_transfer_allowance;
protected_state_version;
status.
A representative progression is:
AVAILABLE → RESERVED → ADMITTED → CONSUMED.
The hardware controller prevents unauthorized duplicate admission
under the same restricted grant.
Where a capability authorizes a bounded number of transfers or a
defined network flow, the applicable usage limits are enforced.
Consumption of an authorization record does not automatically prove
that an external receiving service completed its subsequent
operation.
11.18.31. WF-18.31 — Attestation-State Revocation at Distributed
Controllers
Where multiple SmartNICs, DPUs, or rack-boundary controllers are
permitted to accept capabilities from the same governance node, each
participating controller verifies the required registered governance
state.
The system may distribute authenticated attestation-state updates
containing:
governance_node_id;
previous_attestation_generation;
new_attestation_generation;
approved_measurement_reference;
policy_epoch;
revocation_state;
affected_capability_classes;
Das Expires 19 April 2027 [Page 768]
Internet-Draft Protected AI Execution Finality October 2026
affected_effectuation_sinks;
protected_authentication.
Each affected controller verifies the updates according to its
required freshness and consistency rules.
An authorization accepted at one Finality Sink does not automatically
authorize a different operation at another.
Where current attestation-state verification is mandatory, the
controller refuses affected capabilities when that state cannot be
established.
The architecture does not assume instantaneous propagation across an
arbitrary distributed network. Its actual revocation guarantee
depends upon enforceable update, expiry, or freshness mechanisms.
11.18.32. WF-18.32 — Illustrative Confidential Governance VM and
SmartNIC Deployment
In one implementation, an AI compute server runs an autonomous agent
that generates external network requests.
A separate governance compute node runs in a confidential virtual
machine.
The governance node has a hardware-rooted attestation identity and
access to protected capability-issuance operations.
A SmartNIC controls the governed external network interface.
The AI agent prepares a request to transmit data to an authorized
enterprise service.
The operation is intercepted and staged.
The governance node supplies an authenticated attestation record
identifying its protected execution configuration.
PED-1806 verifies the attestation record against the registered
governance identity, approved hardware trust root, and required
current policy state.
DC-1811 constructs the Candidate Act Descriptor identifying the
source, requested operation, destination, payload or data-class
scope, authorized SmartNIC egress boundary, policy epoch, and
required freshness state.
Das Expires 19 April 2027 [Page 769]
Internet-Draft Protected AI Execution Finality October 2026
PED-1806 validates the Candidate Act-specific authority.
The protected system completes its required state and evidence
procedures.
CR-1814 releases an operation-scoped capability authenticated using
protected governance key material.
FM-1815 conveys the capability through an authenticated management
interface to HC-1816.
The SmartNIC verifies the capability against the actual external
operation, designated egress boundary, registered governance
attestation state, and mandatory current authorization conditions.
If verification succeeds, the SmartNIC permits the scoped
transmission.
If the capability or required governance attestation state is
invalid, the SmartNIC prevents that operation from crossing its
controlled external-transmission boundary.
11.18.33. WF-18.33 — Illustrative Compromised AI Compute Process
An ordinary AI compute process is compromised and attempts to
generate unauthorized external traffic.
The process can prepare a network request but cannot extract the
governance private key from KS-1808.
It attempts to create a capability by supplying an unauthorized
destination.
PED-1806 evaluates the actual Candidate Act and applicable Authority
Object.
The destination violates the required operation scope.
The protected capability is withheld.
The SmartNIC does not permit the unverified request through the
governed forwarding path.
If the process instead presents a forged capability, the hardware
Finality Sink rejects its authentication or registered-issuer
conditions.
Das Expires 19 April 2027 [Page 770]
Internet-Draft Protected AI Execution Finality October 2026
The protection assumes that the compromised compute process cannot
bypass the hardware-controlled effectuation interface under the
implementation's threat model.
11.18.34. WF-18.34 — Illustrative Governance Firmware Measurement
Change
A governance VM operates under an approved firmware and software
measurement.
The system has registered the corresponding acceptable attestation
state.
A firmware or protected software configuration change occurs.
The new attestation state does not match the approved condition.
PED-1806 refuses further execution-capability issuance dependent upon
that governance node.
The affected hardware Finality Sink also enforces any mandatory
current registered-attestation-state restriction when verifying
subsequent capabilities.
Following an authorized revalidation of the changed governance
configuration, the protected system may register a new acceptable
attestation generation.
New Candidate Acts must still satisfy their own operation-specific
authorization requirements.
11.18.35. WF-18.35 — Illustrative Hardware-Freshness Replay Attack
An authorized governance node issues a single-use network-
transmission capability bound to a protected device sequence and boot
epoch.
The SmartNIC verifies the capability and admits the specified
operation.
The relevant protected usage or freshness state advances.
An attacker later restores an earlier governance VM snapshot and
attempts to reuse the previously valid capability.
The protected hardware-freshness or consumption state no longer
matches the authorization.
Das Expires 19 April 2027 [Page 771]
Internet-Draft Protected AI Execution Finality October 2026
The SmartNIC refuses the attempted replay.
The snapshot's earlier view of capability validity does not override
the current protected hardware state.
11.18.36. WF-18.36 — Crash, Reset, and Recovery
The architecture distinguishes different failure stages.
Failure before governance attestation succeeds: Capability issuance
dependent upon the governance node remains unavailable.
Failure after attestation but before Candidate Act authorization: An
acceptable attestation does not independently create operation
authority.
Failure during protected authorization: An incomplete mandatory
authorization or state transition does not produce a usable
capability.
Failure during capability delivery: The effectuation controller must
not treat an unauthenticated or partially installed capability as
valid.
Failure after capability installation but before hardware admission:
The Finality Sink verifies current required attestation, capability,
policy, and freshness state before permitting effectuation.
Failure after possible network transmission: The operation may be
classified as completed or indeterminate according to available
effectuation evidence.
Governance VM snapshot restoration: Required protected freshness and
capability-consumption state remain authoritative.
SmartNIC or DPU reset: The controller restores or revalidates
capability state according to its protected hardware-freshness and
policy conditions.
Governance software update: A changed mandatory measurement requires
revalidation before dependent new capability issuance.
An indeterminate external operation is not automatically replayed
when repetition could cause a duplicate consequence.
Authenticated operation identifiers, hardware completion records,
protected counters, and receiving-side status records may support
recovery where available.
Das Expires 19 April 2027 [Page 772]
Internet-Draft Protected AI Execution Finality October 2026
11.18.37. WF-18.37 — Alternative Technical Implementations
Confidential governance VM with SmartNIC: The governance authority
runs within a confidential VM, and the SmartNIC controls outbound
transmission.
Confidential governance VM with DPU: The DPU verifies the required
capability through its protected network-forwarding or data-path
controls.
Rack-boundary enforcement: A protected rack-boundary controller
verifies capabilities for designated compute nodes before forwarding
traffic beyond the governed boundary.
Accelerator-egress implementation: A protected accelerator-output
interface verifies operation-specific authority before exporting
model or tensor data.
Protected network-controller implementation: A hardware network
controller verifies the required governance identity, attestation
state, and operation capability.
HSM-assisted governance: Protected issuance keys remain under HSM
control while the governance VM performs authenticated authorization
coordination.
Single-node implementation: Governance and hardware finality
functions are integrated within one physical system while retaining
the specified confidentiality, attestation, and independent
verification relationships.
Distributed implementation: The AI compute node, confidential
governance node, and hardware Finality Sink operate on separate
authenticated physical nodes.
Multi-controller implementation: Several hardware effectuation
controllers accept bounded capabilities according to their
independently verified sink identity and registered governance state.
The implementation must demonstrate the actual trust-root, protected
key, enforcement-path, and attestation-state guarantees it claims.
11.18.38. WF-18.38 — Failure and Fail-Closed Conditions
The governed external operation is refused when any mandatory
condition is absent, invalid, expired, revoked, inconsistent, or
unverifiable.
Das Expires 19 April 2027 [Page 773]
Internet-Draft Protected AI Execution Finality October 2026
Non-limiting conditions include:
(a) invalid governance VM attestation;
(b) unregistered governance identity;
(c) failed hardware trust-root verification;
(d) invalid hardware-vendor certificate chain;
(e) invalid registered public-key trust root;
(f) governance firmware measurement mismatch;
(g) incompatible confidential-VM policy version;
(h) invalid launch measurement;
(i) required host-data mismatch;
(j) invalid protected device identity;
(k) unavailable protected governance-key operation;
(l) unauthorized Candidate Act;
(m) invalid Authority Object;
(n) missing execution capability;
(o) invalid capability authentication;
(p) unauthorized effectuation boundary;
(q) actual-operation descriptor mismatch;
(r) registered attestation-state mismatch;
(s) stale policy epoch;
(t) revoked capability;
(u) expired or replayed nonce;
(v) hardware-freshness mismatch;
(w) consumed or exhausted capability;
Das Expires 19 April 2027 [Page 774]
Internet-Draft Protected AI Execution Finality October 2026
(x) unauthenticated fabric-management message;
(y) incorrect Finality Sink identity;
(z) failure of mandatory hardware-interlock verification; or
(aa) an accessible bypass path defeating the specified hardware-
enforced effectuation boundary.
An invalid or unavailable mandatory security condition does not
create unrestricted fallback permission.
11.18.39. WF-18.39 — PHOSITA Verification and Negative Tests
A person having ordinary skill in confidential computing, hardware
attestation, SmartNIC/DPU engineering, secure boot, cryptography,
network forwarding, distributed authorization, or protected execution
may verify the architecture through controlled testing.
Test 1 — Valid attestation and authorized act: Present a valid
governance attestation and matching operation-specific capability.
The hardware Finality Sink admits the authorized transmission.
Test 2 — Valid attestation without capability: Present an acceptable
governance attestation but no act-specific capability. Transmission
is refused.
Test 3 — Unauthorized Candidate Act: Submit an operation outside the
applicable Authority Object. Capability issuance is denied.
Test 4 — Invalid attestation signature: Supply a forged attestation
object. PED verification fails.
Test 5 — Unregistered governance node: Attempt issuance through an
unregistered governance identity. Protected verification fails.
Test 6 — Wrong hardware trust root: Present a chain that does not
satisfy the configured trust policy. Attestation is rejected.
Test 7 — Governance firmware mismatch: Modify a required firmware
measurement. Issuance is withheld pending revalidation.
Test 8 — Confidential VM launch mismatch: Change a required launch
measurement. The approved attestation condition fails.
Test 9 — Policy version mismatch: Present an unauthorized
confidential-VM policy version. Protected verification refuses
dependent authorization.
Das Expires 19 April 2027 [Page 775]
Internet-Draft Protected AI Execution Finality October 2026
Test 10 — Host-data mismatch: Alter a required attested host-data
field. The corresponding predicate fails.
Test 11 — Key extraction attempt: Attempt unrestricted governance-key
access from the AI compute process. Access is denied under the
configured protected-key model.
Test 12 — Forged capability: Present an unauthenticated or
incorrectly authenticated capability. The hardware Finality Sink
refuses it.
Test 13 — Issuer substitution: Present a valid-looking capability
associated with another governance identity. Required issuer binding
fails.
Test 14 — Destination substitution: Authorize one destination and
attempt a different transmission. The Finality Sink rejects the
mismatch.
Test 15 — Boundary substitution: Present a capability at a hardware
boundary not authorized by its scope. Verification fails.
Test 16 — Management-channel tampering: Modify capability data in
transit. Authenticated delivery or capability verification detects
the change.
Test 17 — Capability installed without valid act: Attempt to activate
a forwarding rule without valid operation-specific authority. The
controlled effect remains blocked.
Test 18 — Revoked attestation state: Invalidate the required
governance attestation and verify that affected capability issuance
or use is refused according to the mandatory state rules.
Test 19 — Revalidated attestation: Complete authorized revalidation
of an updated governance measurement and verify that new issuance
remains subject to act-specific predicates.
Test 20 — Hardware monotonic-counter replay: Reuse authorization tied
to an incompatible earlier protected counter state. The Finality
Sink rejects it.
Test 21 — Secure boot epoch mismatch: Replay a capability from an
invalid previous boot epoch. Required freshness verification fails.
Test 22 — Hardware nonce replay: Reuse an invalidated hardware-
attested nonce. The affected operation is refused.
Das Expires 19 April 2027 [Page 776]
Internet-Draft Protected AI Execution Finality October 2026
Test 23 — Governance VM snapshot restoration: Restore a previous
snapshot and attempt reuse of consumed authority. Protected current
state prevents unauthorized replay.
Test 24 — DPU reset: Reset the effectuation controller and verify
that stale protected authorization is not treated as valid without
required revalidation.
Test 25 — Concurrent capability use: Submit competing transfers
against one restricted grant. Protected consumption prevents
unauthorized duplicate effectuation.
Test 26 — Alternative network path: Attempt to bypass the SmartNIC or
designated network controller. The governed effect remains blocked
or equivalently mediated under the specified path coverage.
Test 27 — Hardware versus software-only allow: Remove the protected
capability while preserving an upstream software allow status. The
hardware Finality Sink continues to block effectuation.
Test 28 — Wrong Finality Sink: Present a capability for another
protected interface. Required sink binding fails.
Test 29 — Single-node configuration: Integrate governance and
hardware enforcement functions within one node and verify that the
required protected authority and finality checks remain enforced.
Test 30 — Distributed configuration: Run the AI compute node,
governance VM, and hardware Finality Sink on separate nodes. Verify
the authenticated attestation, capability-delivery, and effectuation
sequence.
Test 31 — Issuer measurement changed after capability issuance:
Change a mandatory governance measurement and verify whether the
selected current-attestation-state enforcement invalidates affected
outstanding capabilities as required.
Test 32 — Indeterminate external completion: Interrupt communication
after a transfer may have occurred. Recovery preserves accurate
completion or indeterminate status rather than assuming the transfer
was prevented.
These tests may employ a confidential-VM development platform,
attestation test fixtures, protected signing services, programmable
SmartNIC/DPU hardware, controlled network interfaces, capability-
state stores, hardware-freshness emulators, and fault-injection
facilities.
Das Expires 19 April 2027 [Page 777]
Internet-Draft Protected AI Execution Finality October 2026
Test outcomes establish only the technical guarantees demonstrated by
the actual implementation and threat model.
11.18.40. WF-18.40 — Claim-Specific Technical Support
Enforcement Point 79 — Confidential Governance VM and Hardware-
Attested SmartNIC Finality
The workflow provides:
(a) AI-1801 as the AI compute node producing a proposed external
operation;
(b) GC-1802 as the confidential governance compute node;
(c) HA-1803 as the hardware-rooted attestation component;
(d) PED-1806 verifying the governance attestation against the
approved trust root, registered governance identity, and protected
policy state;
(e) protected act-specific authorization and capability release;
(f) FM-1815 providing the authenticated fabric-management path;
(g) HC-1816 and FS-1817 as the hardware-associated effectuation
controller and Finality Sink;
(h) independent capability verification against the actual Candidate
Act, effectuation boundary, and registered governance attestation
state; and
(i) prevention of governed external transmission when required
attestation or capability verification fails.
Enforcement Point 80 — Confidential VM Attestation Object
WF-18.6 and WF-18.7 describe the Hardware Finality Gate Attestation
Object, including governance firmware digest, confidential-VM policy
version, launch measurement, host-data field, hardware signing
evidence, and protected device identity, with verification against
the appropriate vendor certificate chain or registered trust root.
Enforcement Point 81 — Confidential Governance-Key Isolation
Das Expires 19 April 2027 [Page 778]
Internet-Draft Protected AI Execution Finality October 2026
WF-18.9 and WF-18.10 describe protected custody of governance or
capability-issuance key material and authenticated communication from
the ordinary AI compute process without unrestricted access to the
keys.
Enforcement Point 82 — Attestation Change Disables Capability
Issuance
WF-18.26 and WF-18.27 describe invalidation of the required approved
governance measurement condition following firmware, launch, policy,
or protected configuration changes and refusal of further dependent
capability issuance pending successful revalidation.
Enforcement Point 83 — Cryptographically Bound Hardware Freshness
WF-18.28 and WF-18.29 describe binding the capability to trusted
monotonic counters, secure boot epochs, protected clocks, device
sequences, or hardware-attested nonces, preventing replay when
current protected freshness state is incompatible with the presented
capability.
11.18.41. WF-18.41 — Technical Effect
The workflow establishes an enforceable dependency between:
(a) AI computation generating a proposed external operation;
(b) protected execution of a governance component within a
confidential virtual machine;
(c) hardware-rooted authentication of governance identity and
execution configuration;
(d) verification of the governance attestation against registered
trust roots and protected policy;
(e) interception and Non-Effective State staging of the Candidate
Act;
(f) act-specific protected authorization;
(g) protected capability generation without exposing unrestricted
governance keys to the AI compute process;
(h) authenticated capability delivery to a hardware effectuation
controller;
Das Expires 19 April 2027 [Page 779]
Internet-Draft Protected AI Execution Finality October 2026
(i) independent verification against the concrete operation,
authorized effectuation boundary, and registered issuer attestation
state;
(j) hardware-enforced external transmission only upon successful
verification;
(k) refusal following invalid required governance measurements; and
(l) hardware-freshness checks preventing reuse of authorization
material outside its permitted device-state context.
The confidential governance VM protects specified governance
computation and key-management functions.
The attestation mechanism establishes the approved identity and
measured configuration of the governance node.
The protected authorization procedure determines whether a particular
Candidate Act is permitted.
The SmartNIC, DPU, or equivalent hardware Finality Sink enforces that
authorization at the actual governed external-transmission boundary.
These are related but distinguishable technical functions.
Computation is not authority to act.
Confidential governance execution is not itself permission for a
Candidate Act.
Hardware attestation establishes an approved trust condition, not
unrestricted external-operation authority.
An authenticated management channel does not replace act-specific
Finality Sink verification.
The hardware Finality Sink must refuse the effect when mandatory
governance attestation or capability conditions fail.
11.19. WF-19 — User-Controlled Confidential Virtual Machine, Root-Key
Sovereignty, Attested Derived-Key Release, Separate Data-Access
and Execution Authority, Privacy-Preserving Finality Evidence,
and Rollback-Resistant Recovery
Das Expires 19 April 2027 [Page 780]
Internet-Draft Protected AI Execution Finality October 2026
11.19.1. WF-19.1 — Technical Purpose
This embodiment describes a computer-implemented architecture for
executing an artificial-intelligence agent within a cloud-hosted
confidential virtual machine while maintaining separate controls over
protected data confidentiality and authority to perform externally
effective operations.
The system comprises a confidential virtual-machine environment,
cryptographic data-protection component, hardware-rooted attestation
mechanism, protected key-enablement component, AI execution
environment, Protected Enforcement Domain, protected evidence-
commitment mechanism, and one or more Finality Sinks.
Protected user data, agent memory, connected-service information, or
task state is encrypted using user-controlled or user-authorized
cryptographic material.
The AI workload may receive bounded access to protected information
only when its confidential-VM measurement and user-authorized data-
access conditions are satisfied.
However, successful access to or decryption of protected data does
not independently confer authority to transmit that data, export
files, apply connected-service credentials, modify persistent state,
or perform another consequential operation.
A proposed externally effective operation is classified as a
Candidate Act and maintained in a Non-Effective State.
The Protected Enforcement Domain validates the Candidate Act against
operation-specific authority, execution context, policy state,
freshness, and intended effectuation boundary.
Following successful protected validation, the required validation
evidence is committed before, or atomically with, release of an
operation-specific execution capability.
The corresponding Finality Sink independently verifies the capability
before permitting the governed consequence.
The architecture therefore establishes two distinct protected
authorization relationships:
Data-access authorization: Whether the specified AI workload may
obtain bounded use of protected information.
Das Expires 19 April 2027 [Page 781]
Internet-Draft Protected AI Execution Finality October 2026
Execution-finality authorization: Whether a concrete consequential
operation involving that information may become externally effective.
Neither authorization automatically substitutes for the other.
11.19.2. WF-19.2 — Participating Technical Components
In one non-limiting implementation, the system comprises:
CV-1901 — Cloud-Hosted Confidential Virtual Machine
A confidential VM configured to host an AI agent, protected task
state, user memory, or connected-service data.
AE-1902 — Artificial-Intelligence Execution Environment
The model, agent, tool runtime, or orchestration component executing
within CV-1901.
DP-1903 — Cryptographic Data-Protection Component
A mechanism configured to encrypt or otherwise cryptographically
protect designated user data.
RK-1904 — User-Controlled Root-Key Authority
A user-controlled cryptographic authority or external key service
operating under user authorization and retaining the applicable root
encryption key.
HA-1905 — Hardware-Rooted Attestation Component
A component configured to provide authenticated measurements of the
confidential VM and its applicable software and security
configuration.
KV-1906 — Protected Attestation Verification Component
A mechanism configured to verify the authenticity, freshness,
identity, and required measurements of the confidential-VM
attestation.
KE-1907 — Protected Key-Enablement Component
A mechanism configured to provide a permitted derived key, wrapped
key, session-limited key, decryption-enabling secret, or bounded
cryptographic operation only upon satisfaction of required data-
access conditions.
Das Expires 19 April 2027 [Page 782]
Internet-Draft Protected AI Execution Finality October 2026
DA-1908 — User Data-Access Authority Store
An authenticated source of user-authorized data-access policies,
permitted datasets, workload identities, access purposes, validity
intervals, and protected authorization state.
IM-1909 — Consequential Operation Interception Component
A controlled interface configured to intercept proposed externally
effective operations generated by AE-1902.
HQ-1910 — Non-Effective Candidate Act Holding Mechanism
A protected or enforcement-controlled queue, buffer, pending request,
or equivalent staging mechanism.
DC-1911 — Candidate Act Descriptor Component
A component configured to construct or verify an effectuation-
relevant descriptor of the proposed consequential operation.
PED-1912 — Protected Enforcement Domain
A protected authority component configured to validate Candidate Acts
independently of successful decryption.
AS-1913 — Operation-Specific Authority Store
An authenticated source of permitted operation classes, destinations,
purposes, workload identities, policy requirements, and designated
Finality Sinks.
PS-1914 — Protected Authorization-State Store
A component maintaining nonce state, revocation epochs, policy
versions, capability-consumption state, and mandatory protected
authorization commitments.
EV-1915 — Protected Validation-Evidence Component
A mechanism configured to commit Candidate Act-specific protected
validation evidence.
CR-1916 — Operation-Specific Execution Capability Mechanism
A protected component configured to generate, release, register, or
activate scoped execution authority.
Das Expires 19 April 2027 [Page 783]
Internet-Draft Protected AI Execution Finality October 2026
FS-1917 — Effectuation Finality Sink
A controlled network, service, credential, file-export, storage-
commit, or other consequential interface configured to verify the
capability before permitting the operation.
ER-1918 — Privacy-Preserving Execution-Evidence Component
A mechanism configured to produce cryptographically authenticated
evidence of protected validation and applicable Finality Sink
verification without unnecessarily disclosing protected plaintext,
reusable credentials, or the root encryption key.
RS-1919 — Rollback-Resistant Authorization State
A protected mechanism maintaining current capability-consumption,
revocation, and required freshness information independently of
rollback-accessible VM backups.
RC-1920 — Confidential-VM Recovery Component
A mechanism configured to reestablish authorized attestation and
reconcile protected key and execution state following recovery.
OS-1921 — Protected Operation-Outcome Store
A mechanism maintaining pending, denied, confirmed-effective,
expired, revoked, or indeterminate operation states.
The functions may be implemented using protected software,
confidential computing, an HSM, TEE, external key authority,
authenticated cloud service, hardware-enforced interface, or a
suitable combination.
11.19.3. WF-19.3 — Separation of Confidentiality and Execution
Authority
The architecture establishes two distinguishable trust domains.
The first governs cryptographic access to protected information.
The second governs the authority to produce consequential effects.
The data-access domain determines whether a confidential VM may
decrypt or use specified protected data.
Das Expires 19 April 2027 [Page 784]
Internet-Draft Protected AI Execution Finality October 2026
The execution-finality domain determines whether a particular
operation prepared by the AI agent may affect an external resource,
recipient, service, file, credential, or persistent state.
For example, an AI agent may be permitted to read a confidential
report for summarization without having permission to email the
report to an external recipient.
Similarly, authority to access connected-service information does not
automatically permit the agent to use a connected-service credential
to perform an unrelated transaction.
The separate control is enforced through distinct protected
authorization conditions rather than an assumption that
confidentiality automatically guarantees safe behavior.
11.19.4. WF-19.4 — Confidential Virtual-Machine Establishment
CV-1901 is instantiated within a cloud-hosted confidential-computing
environment.
The environment may provide:
(a) hardware-protected VM memory;
(b) measured workload launch;
(c) virtual-machine integrity measurement;
(d) authenticated attestation reports;
(e) protected guest execution;
(f) security-configuration measurements;
(g) isolated runtime memory; and
(h) controlled access to protected external key services.
The implementation determines which protections are available against
privileged host access, hypervisor compromise, firmware compromise,
memory disclosure, rollback, and other threats.
The confidential VM does not automatically obtain authority to
perform every external action merely because its execution
environment is successfully attested.
Das Expires 19 April 2027 [Page 785]
Internet-Draft Protected AI Execution Finality October 2026
11.19.5. WF-19.5 — User-Controlled Root-Key Establishment
in the implementation described by enforcement point 85, RK-1904
maintains a root encryption key under the control of a user or user-
authorized external key authority.
The root key may be maintained within:
(a) a user-controlled HSM;
(b) a user-authorized cloud key-management service;
(c) an external protected key vault;
(d) a protected device or secure element;
(e) a user-controlled cryptographic authority; or
(f) another suitable protected key-custody arrangement.
The root encryption key is not made available for unrestricted
extraction by the AI agent.
The root authority may be used to derive, wrap, authorize, or control
bounded data-access material.
The mere existence of a user-controlled root key does not
independently establish permission to release data outside the user's
authorized execution scope.
11.19.6. WF-19.6 — Protected User-Data Encryption
DP-1903 protects designated information using encryption associated
with the user-controlled or user-authorized key material.
Protected information may include:
(a) user documents;
(b) private agent memory;
(c) connected-service data;
(d) task context;
(e) retained application state;
(f) private model inputs;
Das Expires 19 April 2027 [Page 786]
Internet-Draft Protected AI Execution Finality October 2026
(g) encrypted storage volumes;
(h) stored execution-history records; or
(i) other designated user information.
An illustrative encrypted object contains:
encrypted_object_id;
ciphertext_reference;
encryption_algorithm_id;
key_version;
data_scope_id;
tenant_or_user_reference;
integrity_tag;
authorized_access_policy_reference.
The specific encryption scheme must provide the confidentiality and
integrity properties required by the implementation.
An encrypted object is not treated as authorized for external release
merely because its contents can be decrypted by the confidential VM.
11.19.7. WF-19.7 — Hardware-Rooted Confidential-VM Attestation
HA-1905 generates a cryptographically verifiable measurement of the
confidential VM.
The attestation identifies the required software measurement and
security-configuration state.
A non-limiting attestation record comprises:
attestation_id;
vm_identity;
hardware_platform_identity;
vm_launch_measurement;
Das Expires 19 April 2027 [Page 787]
Internet-Draft Protected AI Execution Finality October 2026
workload_software_measurement;
security_configuration;
attestation_nonce;
attestation_generation;
policy_reference;
protected_authentication.
The attestation mechanism may use hardware-supported measurement, a
signed attestation report, a registered attestation key, or another
authenticated measurement technology.
The exact content of the report depends upon the hardware and
virtualized execution platform.
An attestation proves only the measured or authenticated properties
supported by the selected mechanism.
11.19.8. WF-19.8 — Verification of the Confidential-VM Measurement
KV-1906 verifies:
(a) attestation authenticity;
(b) accepted hardware trust root;
(c) correct VM identity;
(d) required software measurement;
(e) approved security configuration;
(f) freshness or challenge association;
(g) applicable workload authorization; and
(h) required protected policy state.
An illustrative predicate is:
Vattest = AuthenticReport AND ApprovedMeasurement AND
ApprovedConfiguration AND CorrectWorkload AND RequiredFreshness
Das Expires 19 April 2027 [Page 788]
Internet-Draft Protected AI Execution Finality October 2026
The predicate succeeds only when its mandatory conditions are
satisfied.
An authentic attestation associated with a different confidential VM
does not authorize key use by the requesting workload.
A valid historical measurement does not automatically authorize use
after an incompatible protected policy or workload change.
11.19.9. WF-19.9 — User-Authorized Data-Access Scope
DA-1908 defines the data-access authority granted by the user or
authorized external key service.
A non-limiting data-access authority may identify:
user_authority_id;
authorized_vm_identity;
authorized_workload_identity;
approved_measurement;
data_scope;
permitted_access_operation;
authorized_purpose;
policy_epoch;
validity_interval;
maximum_usage;
revocation_reference.
The permitted scope may restrict:
(a) which encrypted object may be accessed;
(b) which workload may access the object;
(c) the allowed duration;
(d) the permitted purpose;
Das Expires 19 April 2027 [Page 789]
Internet-Draft Protected AI Execution Finality October 2026
(e) applicable usage count; and
(f) required authorization-state conditions.
The AI agent cannot expand the protected scope simply by requesting a
different object or presenting an application-level assertion that
access is needed.
11.19.10. WF-19.10 — Protected Data-Access Authorization Predicate
KE-1907 verifies the conditions required to enable access to
protected data.
An illustrative predicate is:
Vdata = Vattest AND Puser AND Pscope AND Pworkload AND Pstate
where:
Vdata denotes the data-access authorization result;
Vattest denotes satisfactory VM attestation;
Puser verifies the user-controlled or user-authorized key authority;
Pscope verifies the permitted data-access scope;
Pworkload verifies the requesting workload identity; and
Pstate verifies applicable validity, freshness, revocation, and
protected authorization state.
Successful Vdata permits only the bounded cryptographic access
authorized by the applicable policy.
It does not automatically generate an operation-specific execution
capability.
11.19.11. WF-19.11 — Derived, Wrapped, or Session-Limited Key Release
in the implementation described by enforcement point 85, the
protected key-enablement component makes available a derived,
wrapped, or session-limited key only when the required attestation
and data-access authorization conditions succeed.
The key may be restricted to:
(a) a user-data scope;
Das Expires 19 April 2027 [Page 790]
Internet-Draft Protected AI Execution Finality October 2026
(b) workload identity;
(c) validity interval;
(d) protected authorization state;
(e) encryption-object class;
(f) authorized computation session; or
(g) permitted cryptographic operation.
An illustrative key-release authorization record comprises:
key_release_id;
user_authority_reference;
attested_vm_identity;
approved_measurement_reference;
data_scope;
key_version;
session_reference;
validity_interval;
policy_epoch;
nonce;
protected_authentication.
The root encryption key remains under user or user-authorized
external authority and need not be disclosed to the AI agent.
11.19.12. WF-19.12 — Illustrative Protected Key Derivation
A non-limiting implementation may derive a bounded data-access key
using a suitable key-derivation function.
For example:
Ksession = KDF(Kroot, Context)
Das Expires 19 April 2027 [Page 791]
Internet-Draft Protected AI Execution Finality October 2026
where Context is an unambiguous encoding of permitted key-use
attributes, including the user-data scope, workload identity, key
version, session, and policy state where required.
An implementation using a wrapped-key design may instead perform:
WrappedKey = Wrap(Ktransport, Ksession, AssociatedContext)
The confidential VM receives or obtains access to the bounded key
only after successful required attestation and authority validation.
The root key is not exported to the agent.
These expressions are implementation examples.
The specific construction must use an appropriate cryptographic key-
derivation or wrapping method with the security properties required
by its threat model.
11.19.13. WF-19.13 — Bounded Cryptographic Data Access
Following successful protected key enablement, CV-1901 may decrypt
the authorized information or obtain a bounded cryptographic
operation.
The access may comprise:
(a) decrypting an approved document;
(b) opening a protected agent-memory object;
(c) accessing permitted connected-service data;
(d) recovering an encrypted task state;
(e) deriving a session-limited data key; or
(f) performing another authorized data-access operation.
The resulting plaintext or computation state remains governed by the
relevant execution environment and applicable downstream effectuation
boundaries.
Permission to decrypt does not automatically permit the AI agent to
disclose the plaintext outside the authorized environment.
Das Expires 19 April 2027 [Page 792]
Internet-Draft Protected AI Execution Finality October 2026
11.19.14. WF-19.14 — Dual Authorization for Data Access and External
Effect
in the implementation described by enforcement point 86, data-access
authorization and execution-finality authorization are represented by
distinct protected conditions.
An illustrative relationship is:
DataAccessAllowed = Vdata
ExternalEffectAllowed = Veffect
where Vdata governs bounded decryption or data use, and Veffect
governs the separately proposed consequential operation.
The architecture does not assume:
Vdata implies Veffect.
A successful decryption operation does not automatically create the
operation-specific execution capability.
The Finality Sink independently checks Veffect through the required
capability and protected-state conditions.
Where the proposed consequential operation requires access to
protected data, both conditions may be necessary.
A failure of either mandatory condition causes the corresponding
protected operation to be withheld.
11.19.15. WF-19.15 — Candidate Act Generation
AE-1902 processes data available within its authorized scope.
The agent may prepare a consequential operation comprising:
(a) an external network request;
(b) a file export;
(c) an email or messaging operation;
(d) a credential-mediated service invocation;
(e) a persistent record modification;
Das Expires 19 April 2027 [Page 793]
Internet-Draft Protected AI Execution Finality October 2026
(f) a database write;
(g) a protected document publication;
(h) a financial instruction; or
(i) another externally effective operation.
The proposed operation is classified as Candidate Act CA-1922.
Generation of CA-1922 does not constitute authority to execute it.
A user-approved data-decryption event does not independently
authorize the resulting operation.
11.19.16. WF-19.16 — Interception and Non-Effective State
IM-1909 intercepts CA-1922 before the corresponding governed
effectuation boundary.
HQ-1910 retains it in a Non-Effective State.
An illustrative staging record comprises:
candidate_act_id;
vm_identity;
workload_identity;
data_access_reference;
operation_class;
destination_reference;
payload_reference;
policy_epoch;
finality_sink_id;
status = NON_EFFECTIVE.
The proposed operation remains held while the Protected Enforcement
Domain evaluates the required act-specific authority.
Das Expires 19 April 2027 [Page 794]
Internet-Draft Protected AI Execution Finality October 2026
Where the request contains mutable parameters, the interception
mechanism retains an immutable representation or authenticated digest
sufficient for later Finality Sink comparison.
11.19.17. WF-19.17 — Canonical Candidate Act Descriptor
DC-1911 constructs a canonical Candidate Act Descriptor.
The descriptor identifies the proposed consequential effect and its
required authorization context.
A non-limiting descriptor comprises:
candidate_act_id;
vm_identity;
attested_measurement_reference;
workload_identity;
user_authority_reference;
authorized_execution_scope;
operation_class;
destination_or_recipient;
resource_identifier;
effectuation_parameters;
payload_digest;
policy_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_id.
The applicable Authority Object determines which fields are
mandatory.
Das Expires 19 April 2027 [Page 795]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative encoding is:
Dact = Canon_v(VM, ATTEST, USER_SCOPE, ACT, TARGET, PARAM, EPOCH,
NONCE, SINK)
where the fields represent the required attested VM, user-authorized
execution scope, concrete operation, destination, effectuation
parameters, policy epoch, freshness, and Finality Sink identity.
An illustrative digest is:
hAct = H("DAS-USER-CVM-ACT-v1" || Encode(Dact))
The particular encoding and cryptographic algorithms are
implementation choices.
11.19.18. WF-19.18 — Operation-Specific Authority Validation
PED-1912 obtains the applicable operation-specific Authority Object.
It validates:
(a) actual Candidate Act operation class;
(b) permitted user-authorized execution scope;
(c) workload and VM identity;
(d) required confidential-VM attestation;
(e) destination or recipient;
(f) operation parameters;
(g) execution purpose;
(h) current policy epoch;
(i) revocation state;
(j) nonce and freshness;
(k) capability-use restrictions; and
(l) intended effectuation boundary.
An illustrative predicate is:
Das Expires 19 April 2027 [Page 796]
Internet-Draft Protected AI Execution Finality October 2026
Veffect = Pact AND Pscope AND Pattest AND Pcontext AND Pstate AND
Psink
where each term represents the corresponding mandatory authorization
condition.
Successful data-access authorization may form part of the context
where required.
However, operation-specific authority is independently evaluated.
11.19.19. WF-19.19 — Protected Authorization-State Handling
Following successful validation, PED-1912 performs the protected
state operation required for CA-1922.
Possible operations include:
(a) reserving a single-use execution grant;
(b) registering or consuming a nonce;
(c) validating the current policy epoch;
(d) checking revocation state;
(e) recording the Candidate Act digest;
(f) reserving a bounded capability identifier;
(g) updating a usage allowance; or
(h) establishing another required protected authorization transition.
Where an execution grant is single-use, protected state prevents
unauthorized concurrent or repeated consumption.
Where the required state transition cannot be established, the
execution capability is withheld.
11.19.20. WF-19.20 — Protected Validation-Evidence Commitment
EV-1915 commits validation evidence corresponding to CA-1922.
An illustrative record comprises:
receipt_id;
Das Expires 19 April 2027 [Page 797]
Internet-Draft Protected AI Execution Finality October 2026
candidate_act_id;
candidate_act_descriptor_digest;
attested_vm_reference;
user_execution_scope_reference;
authority_object_reference;
policy_epoch;
protected_state_transition;
nonce;
finality_sink_id;
authorization_result;
protected_authentication.
The evidence may comprise a LAVR, AVR, authenticated validation
receipt, sealed commitment, or another protected record.
The evidence is committed before, or atomically with, release of the
operation-specific capability, as required by enforcement point 84.
An ordinary log created after data transmission does not substitute
for the required pre-release evidence commitment.
11.19.21. WF-19.21 — Protected Execution-Finality Transaction
The protected system coordinates authorization, required state
transition, evidence commitment, and capability availability.
An illustrative transaction is:
(Snext, Ract, Ready) = CommitExecutionFinality(Dact, A, Scurrent, F)
where:
Snext denotes committed protected authorization state;
Ract denotes committed validation evidence;
Ready denotes completion of mandatory authorization prerequisites;
Das Expires 19 April 2027 [Page 798]
Internet-Draft Protected AI Execution Finality October 2026
Dact denotes the validated Candidate Act Descriptor;
A denotes authenticated operation authority;
Scurrent denotes prior protected state; and
F denotes the Finality Sink.
No valid operation-specific capability becomes available while a
mandatory protected authorization or evidence dependency remains
incomplete.
This transaction does not imply that an arbitrary remote recipient
participates in the same atomic transaction.
11.19.22. WF-19.22 — Cryptographically Bound Operation-Specific
Capability
in the implementation described by enforcement point 87, CR-1916
releases a capability cryptographically bound to:
(a) the canonical Candidate Act Descriptor;
(b) the attested confidential-VM measurement;
(c) the user-authorized execution scope;
(d) a policy epoch;
(e) a nonce; and
(f) the designated Finality Sink identity.
A non-limiting capability is:
Cact = Sign_skPED(Encode(hAct, hR, VMmeasurement, UserScope, Epoch,
Nonce, Expiry, Sink))
where:
Cact denotes the execution capability;
hAct denotes the Candidate Act commitment;
hR denotes the protected validation-evidence commitment;
VMmeasurement denotes the required attested execution-context
measurement;
Das Expires 19 April 2027 [Page 799]
Internet-Draft Protected AI Execution Finality October 2026
UserScope denotes permitted user-authorized effectuation scope;
Epoch denotes the required protected policy epoch;
Nonce denotes freshness;
Expiry denotes the capability validity limit; and
Sink denotes the designated Finality Sink.
The capability may alternatively be represented through a MAC, sealed
handle, protected capability table, or equivalent authenticated
mechanism.
The required cryptographic and protected-state bindings prevent
unauthorized reuse outside the permitted context.
11.19.23. WF-19.23 — Independent Finality Sink Verification
FS-1917 obtains the actual proposed consequential operation and
corresponding execution capability.
Before permitting the governed effect, the Finality Sink verifies:
(a) capability authenticity;
(b) required Candidate Act Descriptor correspondence;
(c) attested VM measurement;
(d) user-authorized execution scope;
(e) operation type;
(f) destination or recipient;
(g) required policy epoch;
(h) nonce and expiry;
(i) protected validation-evidence commitment;
(j) current required revocation and usage state; and
(k) designated Finality Sink identity.
The operation is permitted only when all mandatory checks succeed.
Das Expires 19 April 2027 [Page 800]
Internet-Draft Protected AI Execution Finality October 2026
A successful decryption event is not accepted as a substitute for
execution-capability verification.
A valid execution capability for one operation does not automatically
authorize another operation.
11.19.24. WF-19.24 — Operation and Attestation Substitution Protection
The system verifies that the actual operation remains consistent with
the protected authorization.
Potential substitutions include:
(a) changing the destination;
(b) altering the payload;
(c) changing the recipient;
(d) modifying the operation class;
(e) replacing the attested VM;
(f) changing a mandatory workload measurement;
(g) changing the authorized user scope;
(h) using a capability from another policy epoch; or
(i) presenting the capability at another Finality Sink.
Where an effectuation-relevant parameter or required attested state
changes incompatibly after authorization, capability verification
fails as required by enforcement point 87.
The Finality Sink relies on authenticated actual-operation
information rather than solely upon an agent-supplied description of
the earlier approved operation.
11.19.25. WF-19.25 — Privacy-Preserving Execution Evidence
in the implementation described by enforcement point 88, ER-1918
generates or maintains a cryptographically authenticated execution
record establishing that the specified Candidate Act underwent
protected authority validation and applicable Finality Sink
verification.
The record may contain:
Das Expires 19 April 2027 [Page 801]
Internet-Draft Protected AI Execution Finality October 2026
execution_record_id;
candidate_act_descriptor_digest;
protected_validation_receipt_digest;
attested_vm_reference;
authority_scope_commitment;
capability_identifier;
finality_sink_id;
verification_result;
protected_effectuation_status;
policy_epoch;
protected_authentication.
The record is configured to support verification of the required
enforcement condition without disclosing:
(a) plaintext protected user data;
(b) reusable credential material; or
(c) the user-controlled root encryption key.
The record may use authenticated commitments, signatures, hashes,
protected references, or a suitable privacy-preserving cryptographic
construction.
The specific confidentiality and verification properties depend upon
the selected implementation.
11.19.26. WF-19.26 — Distinction Between Authorization Evidence and
Completion Evidence
The system distinguishes evidence that a Candidate Act satisfied
protected authorization requirements from evidence that the Finality
Sink verified the capability and evidence that the external operation
completed.
An illustrative relationship is:
Das Expires 19 April 2027 [Page 802]
Internet-Draft Protected AI Execution Finality October 2026
Rvalidation — protected authority-validation evidence.
Rverification — evidence of Finality Sink capability verification.
Rcompletion — evidence of the specified effectuation outcome, where
available.
Rvalidation alone does not prove that the operation became effective.
Rverification may establish successful sink verification without
necessarily proving that a remote service completed a subsequent
operation.
Rcompletion reflects the completion semantics of the actual governed
interface.
Where an execution record is required to establish both validation
and applicable Finality Sink verification, the system
cryptographically associates the corresponding records with the same
Candidate Act.
The design does not falsely represent an uncertain external outcome
as confirmed completion.
11.19.27. WF-19.27 — Root-Key Confidentiality During Evidence
Verification
The Finality Sink or external evidence verifier need not receive the
root encryption key.
The verification record may disclose authenticated commitments and
bounded authorization references without revealing sensitive
cryptographic material.
For example, the record may demonstrate that:
(a) the Candidate Act matched the protected operation descriptor;
(b) the permitted execution scope was validated;
(c) the required VM measurement was accepted;
(d) protected validation evidence was committed;
(e) the scoped capability was verified at the intended Finality Sink;
and
(f) the corresponding decision was authenticated.
Das Expires 19 April 2027 [Page 803]
Internet-Draft Protected AI Execution Finality October 2026
The verifier does not require unrestricted access to user plaintext
or reusable credentials to establish these recorded enforcement
facts.
Where zero-knowledge evidence is used, the specified privacy
properties must be provided by an actual appropriate proof
construction.
A conventional signed record is not automatically a zero-knowledge
proof.
11.19.28. WF-19.28 — Separate Key-Access and Execution Revocation
The architecture may maintain distinct revocation conditions for data
access and external effectuation.
For example:
Data-access revocation: The user withdraws permission for the
confidential VM to obtain new bounded access to specified encrypted
information.
Execution-authority revocation: The protected authority invalidates
permission for a particular external operation or class of
operations.
Revocation of a data-access key does not automatically prove that
plaintext already accessed by the workload has been erased.
Similarly, a data-access authorization remaining valid does not
override revoked downstream execution authority.
The applicable protected controls enforce each revocation condition
at the boundary they actually govern.
Where the external operation requires both valid data-access
authority and current execution authorization, failure of either
mandatory condition causes withholding.
11.19.29. WF-19.29 — Confidential-VM Backup and Snapshot Protection
in the implementation described by enforcement point 89, CV-1901 may
be backed up or snapshotted.
The backup may contain:
(a) encrypted VM state;
Das Expires 19 April 2027 [Page 804]
Internet-Draft Protected AI Execution Finality October 2026
(b) protected agent memory;
(c) encrypted task state;
(d) locally cached key references;
(e) pending Candidate Acts;
(f) prior authorization references;
(g) earlier policy-state information; and
(h) application-level operation history.
The system distinguishes restoration of the VM's computational state
from restoration of current protected execution authority.
An earlier backup is not treated as an authoritative source of
current capability-consumption, revocation, or required freshness
state.
The protected execution state is reconciled independently of
rollback-accessible backup contents.
11.19.30. WF-19.30 — Attested Recovery of the Confidential VM
After restoration of an encrypted VM backup, protected agent-memory
snapshot, or recovered confidential-VM instance, RC-1920 establishes
the required authorized attested execution context.
An illustrative recovery sequence includes:
First, restore the permitted encrypted workload state.
Second, identify the recovered confidential VM.
Third, obtain a fresh hardware-rooted attestation or the appropriate
current authenticated measurement.
Fourth, verify the recovered workload and security configuration
against the applicable approved conditions.
Fifth, consult current user-authorized data-access scope.
Sixth, reestablish the required protected key-enablement conditions.
Seventh, obtain current execution-policy and revocation state.
Das Expires 19 April 2027 [Page 805]
Internet-Draft Protected AI Execution Finality October 2026
Eighth, reconcile authoritative capability-consumption state outside
the restored snapshot.
Ninth, identify pending, previously executed, and indeterminate
Candidate Acts.
Tenth, permit further governed effectuation only after the applicable
current authorization and Finality Sink verification succeed.
The recovered VM does not automatically inherit unrestricted
decryption or execution authority from its earlier snapshot.
11.19.31. WF-19.31 — Protected Capability-Consumption State Continuity
RS-1919 maintains the authoritative state required to prevent
restoration of expired, consumed, or revoked capabilities.
A representative state record comprises:
capability_id;
candidate_act_digest;
authorized_vm_identity;
policy_epoch;
nonce;
capability_status;
remaining_uses;
revocation_epoch;
protected_state_version;
effectuation_outcome_reference.
The authoritative state may reside within a protected external state
service, HSM-controlled store, hardware-backed counter, or another
mechanism independent of rollback-accessible VM backups.
The selected mechanism must maintain the state properties required by
its threat model.
Merely retaining a second copy of a file is insufficient when both
copies can be restored to an earlier state by the relevant attacker.
Das Expires 19 April 2027 [Page 806]
Internet-Draft Protected AI Execution Finality October 2026
11.19.32. WF-19.32 — Snapshot-Rollback Replay Protection
Consider an agent that has been authorized to perform a single
externally effective operation.
The Finality Sink verifies and consumes the corresponding capability.
The VM is later restored from a snapshot created before capability
consumption.
The restored VM contains the earlier capability reference.
The agent attempts to reuse that capability.
The Finality Sink consults RS-1919 rather than relying exclusively
upon the restored VM's local state.
The authoritative record indicates that the capability has already
been consumed, expired, or revoked.
The operation is denied.
Restoration of the confidential VM does not restore the previously
invalidated execution capability.
11.19.33. WF-19.33 — User Root-Key Continuity During Recovery
A user-controlled root encryption key may remain under user or
external authority throughout VM recovery.
Restoration of encrypted data does not require unrestricted transfer
of the root key into the AI agent.
Following successful current attestation and user-authorized data-
access verification, KE-1907 may make available a new bounded derived
key, wrapped key, session-limited key, or protected cryptographic
access operation.
The new data-access authorization remains subject to its own scope,
validity, and revocation requirements.
Reestablishing decryption authority does not automatically restore
previously consumed or revoked external execution capabilities.
The data-access and effectuation-authority domains remain separate
after recovery.
Das Expires 19 April 2027 [Page 807]
Internet-Draft Protected AI Execution Finality October 2026
11.19.34. WF-19.34 — Illustrative Confidential AI-Agent Document
Processing
In one implementation, a user stores encrypted documents under a
user-controlled encryption authority.
An AI agent executes within a confidential VM.
The agent requests access to one protected document for an authorized
summarization task.
HA-1905 generates the required confidential-VM attestation.
KV-1906 verifies the approved measurement, workload identity,
security configuration, and freshness.
KE-1907 validates the user-authorized data-access scope.
A bounded key or cryptographic access operation enables the
confidential VM to process the approved document.
The agent generates a summary.
The agent subsequently proposes sending the summary to an external
recipient.
The proposed transmission becomes a Candidate Act.
IM-1909 intercepts the request and retains it in a Non-Effective
State.
PED-1912 validates the recipient, payload scope, authorized purpose,
current policy state, nonce, and designated network Finality Sink.
The required validation evidence is committed.
CR-1916 makes available the operation-specific capability.
The network Finality Sink verifies the capability against the actual
transmission.
If the recipient and operation match the authorized scope,
transmission is permitted.
If the agent attempts to send the complete underlying document to an
unauthorized recipient, the corresponding operation fails the
required protected authorization or descriptor verification.
Das Expires 19 April 2027 [Page 808]
Internet-Draft Protected AI Execution Finality October 2026
The earlier permission to decrypt and summarize does not
independently authorize disclosure of the document.
11.19.35. WF-19.35 — Illustrative Connected-Service Credential
Operation
An AI agent executing in a confidential VM receives bounded access to
protected connected-service data.
The data-access authorization permits the agent to inspect authorized
information.
The agent then proposes a credential-mediated operation that would
modify an external account.
The proposed operation is classified as a separate Candidate Act.
The protected authority verifies the specific account, intended
operation, recipient or resource, permitted purpose, and current
authorization state.
The credential-use Finality Sink verifies the corresponding scoped
capability before protected credential application.
Successful access to encrypted connected-service information does not
permit unrestricted credential-mediated modification.
The agent cannot transform possession of a data-access key into
general execution authority over the connected service.
11.19.36. WF-19.36 — Illustrative VM Snapshot Recovery
An AI agent has previously obtained authorization to export one
protected file.
The corresponding file-export Finality Sink verifies and consumes the
capability.
An earlier encrypted VM backup is later restored.
The restored agent state still contains a reference to the former
export capability.
The recovery component establishes a fresh attested VM context and
checks current data-access policy.
It separately consults the authoritative protected capability-
consumption state.
Das Expires 19 April 2027 [Page 809]
Internet-Draft Protected AI Execution Finality October 2026
The earlier export capability is already consumed.
The restored VM may regain authorized access to data under a new
bounded key-enablement condition, but it cannot reuse the consumed
export capability.
A new export requires its own applicable protected authorization.
11.19.37. WF-19.37 — Failure, Crash, and Recovery Handling
The system distinguishes failures at the cryptographic data-access
boundary and at the consequential effectuation boundary.
Invalid VM attestation: Required bounded data-access key enablement
is withheld.
Invalid user data-access scope: The protected key-enablement
component refuses access to data outside the authorized scope.
Successful decryption but invalid Candidate Act authority: The
consequential operation remains non-effective.
Failure before protected validation-evidence commitment: No valid
corresponding execution capability becomes available.
Failure after evidence commitment but before capability delivery: The
protected system reconciles committed authorization state before
recovery.
Failure after capability availability but before effectuation: The
Finality Sink verifies current protected conditions before permitting
the operation.
Failure after possible external effect: The outcome may be confirmed
or indeterminate depending upon available evidence.
VM snapshot restoration: The recovered VM must satisfy the applicable
attestation, data-access, and protected capability-state conditions.
Root-key rotation: The system determines whether authorized wrapped
or derived keys and encrypted objects remain accessible under the
current key-management policy.
Execution revocation: Previously consumed or revoked capabilities do
not become valid merely because the VM or its encrypted data is
restored.
Das Expires 19 April 2027 [Page 810]
Internet-Draft Protected AI Execution Finality October 2026
An indeterminate consequential operation is not automatically
repeated when unauthorized duplication could result.
11.19.38. WF-19.38 — Alternative Technical Implementations
User-held HSM implementation: The root key is retained within a user-
controlled HSM, with bounded derived-key enablement for an attested
confidential VM.
External key-authority implementation: A user-authorized external
service retains root key control and releases only authorized bounded
cryptographic access.
Wrapped-key implementation: The confidential VM obtains a wrapped or
session-limited data-access key following required attestation
verification.
Cryptographic-operation implementation: Protected data access occurs
through a bounded remote cryptographic operation rather than release
of reusable plaintext key material.
Confidential cloud implementation: The AI agent executes inside a
cloud confidential VM with protected attestation and controlled
external effectuation.
Protected host-gateway implementation: A host-side gateway or trusted
service verifies operation-specific execution capabilities.
Hardware Finality Sink implementation: A SmartNIC, DPU, secure
storage controller, or another hardware-associated effectuation
interface performs required capability verification.
Single-node implementation: The confidentiality and finality
functions operate within one protected node while retaining their
separate authorization conditions.
Distributed implementation: The user root-key authority, confidential
VM, PED, and Finality Sink operate on authenticated separate nodes.
Rollback-resistant recovery implementation: Authoritative capability-
consumption and revocation state is maintained outside guest backups
and snapshots.
Different implementations may provide different protection against
key compromise, privileged host attacks, side channels, cloud-service
compromise, rollback, or unauthorized bypass.
Das Expires 19 April 2027 [Page 811]
Internet-Draft Protected AI Execution Finality October 2026
The actual specified guarantees depend upon the selected
implementation and threat model.
11.19.39. WF-19.39 — Failure and Fail-Closed Conditions
The system withholds the corresponding data-access operation or
consequential effect when a mandatory condition fails.
Non-limiting conditions include:
(a) missing user-authorized key authority;
(b) invalid confidential-VM attestation;
(c) incorrect workload identity;
(d) unapproved software measurement;
(e) invalid security configuration;
(f) unauthorized data scope;
(g) expired data-access grant;
(h) revoked data-access permission;
(i) invalid derived or wrapped key authorization;
(j) unauthorized cryptographic key use;
(k) missing Candidate Act Descriptor;
(l) unauthorized operation class;
(m) unauthorized destination or recipient;
(n) required VM-measurement mismatch;
(o) invalid operation-specific authority;
(p) stale policy epoch;
(q) invalid nonce or freshness state;
(r) failed protected authorization-state transition;
(s) failed validation-evidence commitment;
Das Expires 19 April 2027 [Page 812]
Internet-Draft Protected AI Execution Finality October 2026
(t) missing execution capability;
(u) invalid capability authentication;
(v) Finality Sink mismatch;
(w) consumed or revoked execution capability;
(x) unauthorized snapshot replay;
(y) invalid recovered VM attestation;
(z) failed required protected-state reconciliation; or
(aa) unavailable mandatory effectuation-boundary verification.
The corresponding operation remains non-effective, denied, or subject
to separately authorized recovery.
Failure of execution authorization does not automatically authorize
release of protected plaintext as an alternative.
11.19.40. WF-19.40 — PHOSITA Verification and Negative Tests
A person having ordinary skill in confidential computing,
cryptographic key management, hardware attestation, cloud AI
infrastructure, protected authorization, and distributed security may
perform the following verification tests.
Test 1 — Authorized data access: Provide valid attestation and user-
authorized data scope. Confirm bounded data access.
Test 2 — Attestation mismatch: Change a required VM measurement.
Verify key enablement is refused.
Test 3 — Wrong workload: Attempt key access from another confidential
VM or workload. Required workload binding fails.
Test 4 — Expired data-access grant: Present an expired grant.
Protected key access is refused.
Test 5 — Root-key confidentiality: Verify the AI agent cannot extract
unrestricted user-controlled root key material through the authorized
interface.
Test 6 — Derived-key scope: Attempt access to data outside the
bounded key's permitted scope. Access is denied.
Das Expires 19 April 2027 [Page 813]
Internet-Draft Protected AI Execution Finality October 2026
Test 7 — Successful decryption without execution authority: Permit
bounded decryption, then attempt an external operation without an
execution capability. The Finality Sink refuses the effect.
Test 8 — Unauthorized recipient: Prepare an export to a recipient
outside the permitted execution scope. Protected validation fails.
Test 9 — Payload substitution: Authorize one payload and substitute a
materially different required payload. Finality Sink verification
fails.
Test 10 — Attested-state substitution: Present a capability
associated with another required VM measurement. Verification fails.
Test 11 — Policy epoch mismatch: Present a capability under an
incompatible current policy epoch. Effectuation is refused.
Test 12 — Expired nonce: Reuse an invalid freshness value. Protected
verification fails.
Test 13 — Wrong Finality Sink: Present a capability to an
unauthorized effectuation boundary. Sink binding fails.
Test 14 — Missing validation evidence: Interrupt mandatory evidence
commitment. No valid corresponding capability becomes available.
Test 15 — Receipt confidentiality: Verify the protected execution
record without exposing designated user plaintext or root-key
material.
Test 16 — Reusable credential disclosure: Inspect the authorized
evidence output and verify reusable credentials are not disclosed by
the record.
Test 17 — Different Candidate Act: Reuse valid evidence for a
different operation. Required act binding fails.
Test 18 — Revoked execution grant: Revoke a previously issued
execution capability. Subsequent affected effectuation is refused.
Test 19 — Capability replay: Reuse a consumed single-use capability.
Protected usage-state verification fails.
Test 20 — Concurrent execution: Submit competing operations against a
restricted grant. Protected state prevents unauthorized double
consumption.
Das Expires 19 April 2027 [Page 814]
Internet-Draft Protected AI Execution Finality October 2026
Test 21 — VM snapshot rollback: Restore an earlier VM snapshot
containing a previously consumed capability. The Finality Sink
refuses replay.
Test 22 — Backup recovery attestation: Restore an encrypted VM backup
and verify that a required fresh attested execution context is
established.
Test 23 — Revocation after backup: Revoke a capability after a
snapshot and restore the snapshot. The old capability remains
revoked.
Test 24 — Derived-key recovery: After authorized recovery, verify
bounded data-access key release does not automatically reissue a
consumed execution capability.
Test 25 — Root-key rotation: Rotate the user-controlled root key and
verify access according to the authorized key-version and recovery
policy.
Test 26 — Data-access revocation: Revoke future decryption authority
and verify that affected new key-enablement operations fail.
Test 27 — Independent effectuation authorization: Maintain valid
data-access authority while revoking external operation authority.
Confirm the prohibited effect remains blocked.
Test 28 — Network bypass: Attempt to export protected information
through an alternate accessible effectuation path. The governed
effect remains subject to required enforcement.
Test 29 — Single-node implementation: Verify distinguishable data-
access and execution-finality authorization within one protected
system.
Test 30 — Distributed implementation: Place the root-key authority,
confidential VM, PED, and Finality Sink on separate nodes. Verify
authenticated state and capability consistency.
Test 31 — Crash after possible external effect: Interrupt an
operation after possible remote acceptance. Recovery preserves an
accurate confirmed or indeterminate outcome.
Test 32 — No automatic replay: Verify restoration does not
automatically repeat an operation whose completion is uncertain.
Das Expires 19 April 2027 [Page 815]
Internet-Draft Protected AI Execution Finality October 2026
Test 33 — Protected-state tampering: Attempt to modify authoritative
capability-consumption state from the guest VM. The protected
mechanism rejects unauthorized modification.
Test 34 — Confidentiality versus authority: Demonstrate that a valid
data-access key enables bounded computation without independently
enabling a consequential operation.
These tests may employ confidential-VM development platforms,
authenticated external key services, HSM test systems, synthetic
encrypted datasets, mock AI agents, protected authorization-state
stores, programmable Finality Sinks, snapshot-and-restore tools, and
fault injection.
The results establish only those guarantees actually demonstrated
within the implementation's threat model.
11.19.41. WF-19.41 — Claim-Specific Technical Support
Enforcement Point 84 — User-Controlled Confidential VM with
Cryptographically Bound Execution Authority
The workflow provides:
(a) CV-1901 executing the AI agent while maintaining protected user
data or task state;
(b) DP-1903 encrypting protected information using user-controlled or
user-authorized key material;
(c) HA-1905 generating verifiable confidential-VM measurements;
(d) KE-1907 conditioning bounded key or cryptographic data access on
attestation and user-authorized scope;
(e) AE-1902 preparing an externally effective operation using
authorized data;
(f) PED-1912 classifying that operation as a Candidate Act, holding
it non-effective, and performing operation-specific validation;
(g) EV-1915 committing the required validation evidence before or
atomically with capability release;
(h) FS-1917 independently verifying the operation-specific capability
before effectuation; and
Das Expires 19 April 2027 [Page 816]
Internet-Draft Protected AI Execution Finality October 2026
(i) separate fail-closed conditions for required data-access and
execution-finality authorization.
Enforcement Point 85 — User-Held Root-Key and Attested Derived-Key
Release
WF-19.5 through WF-19.12 describe user or user-authorized root-key
control, attested derived or wrapped key release, bounded session or
data scope, and absence of unrestricted root-key disclosure to the
agent.
Enforcement Point 86 — Dual Authorization for Decryption and External
Effect
WF-19.14 establishes distinct cryptographic or protected-state
conditions for bounded data access and consequential effectuation.
The Finality Sink verifies the execution capability independently of
successful decryption.
Enforcement Point 87 — Cryptographic Binding of Confidential-VM State
to Candidate Act
WF-19.17, WF-19.22 and WF-19.24 describe binding the capability to
the canonical Candidate Act Descriptor, attested VM measurement,
user-authorized execution scope, policy epoch, nonce, and Finality
Sink identity.
Unauthorized modification of a mandatory effectuation parameter or
required attested state causes verification failure.
Enforcement Point 88 — Privacy-Preserving Execution Evidence
WF-19.25 through WF-19.27 describe a cryptographically authenticated
record establishing protected validation and applicable Finality Sink
verification without disclosing protected plaintext, reusable
credentials, or the user-controlled root encryption key.
Enforcement Point 89 — Confidential-VM Recovery and Key-State
Continuity
WF-19.29 through WF-19.33 describe recovery of encrypted VM backups
or agent-memory snapshots, reestablishment of authorized attested
execution context, independent reconciliation of protected capability
state, and rejection of previously expired, consumed, or revoked
capabilities.
Das Expires 19 April 2027 [Page 817]
Internet-Draft Protected AI Execution Finality October 2026
11.19.42. WF-19.42 — Technical Effect
The workflow establishes two protected, distinguishable authorization
dependencies.
The first governs whether a confidential AI workload may obtain
bounded access to user-protected data.
The second governs whether an operation generated using that data may
become externally effective.
The operative sequence includes:
(a) encryption under user-controlled or user-authorized key material;
(b) confidential-VM execution;
(c) hardware-rooted attestation;
(d) verification of approved workload and security state;
(e) conditional bounded key enablement;
(f) authorized data processing by the AI agent;
(g) generation and interception of a Candidate Act;
(h) maintenance of that act in a Non-Effective State;
(i) act-specific protected authority validation;
(j) protected authorization-state handling;
(k) validation-evidence commitment;
(l) operation-specific capability release;
(m) independent verification at the Finality Sink;
(n) controlled effectuation or fail-closed refusal;
(o) privacy-preserving authentication of the enforcement record; and
(p) recovery that reconciles protected execution authority
independently of rollback-accessible VM state.
Das Expires 19 April 2027 [Page 818]
Internet-Draft Protected AI Execution Finality October 2026
This prevents a confidential AI workload from converting successful
access to protected user data into unrestricted authority to
disclose, transmit, export, or modify external resources.
User-controlled root-key custody restricts who may enable access to
protected information.
Attestation restricts the workload environments eligible for bounded
key use.
Candidate Act-specific authorization governs what the AI agent may
cause to happen outside its protected computational context.
The Finality Sink enforces that authority at the actual consequential
boundary.
Rollback-resistant state prevents restoration of an earlier VM backup
from reviving consumed or revoked execution authority.
Computation is not authority to act.
Permission to decrypt is not permission to disclose.
User-controlled root-key access is not unrestricted execution
authority.
Attestation proves specified execution properties, not authorization
for every external action.
Restoration of protected data does not restore consumed execution
capabilities.
11.20. WF-20 — Protected Derived-Key and Wrapped-Key Enablement,
Attestation-Bound Key Release, Cryptographic Key-Use Finality,
Separation of Data Access from Execution Authority, and
Hardware-Enforced Credential and Effectuation Control
11.20.1. WF-20.1 — Technical Purpose
This embodiment describes a computer-implemented protected key-
authority architecture in which cryptographic key access, protected
key use, data decryption, credential enablement, and externally
effective operations are governed by distinguishable authorization
conditions.
The system provides a protected relationship among:
(a) a user-controlled or user-authorized root-key authority;
Das Expires 19 April 2027 [Page 819]
Internet-Draft Protected AI Execution Finality October 2026
(b) an encrypted data object or protected computational state;
(c) an authenticated execution environment;
(d) a protected key-enablement mechanism;
(e) a derived, wrapped, session-limited, or otherwise bounded
cryptographic key;
(f) a separate operation-specific execution authority;
(g) a Protected Enforcement Domain;
(h) a scoped execution capability; and
(i) a Finality Sink controlling the consequential effect.
The AI workload may obtain permission to decrypt designated
information or use a bounded cryptographic key.
However, possession of a key, access to decrypted information, or
successful completion of a cryptographic operation does not
independently confer authority to cause an externally effective
operation.
The system distinguishes at least three technical events:
Key-enablement event: A protected key authority authorizes a
specified cryptographic access operation or makes bounded key
material available to an eligible execution context.
Candidate Act authorization event: A Protected Enforcement Domain
validates a proposed consequential operation against its applicable
operation-specific authority and protected state.
Effectuation event: A designated Finality Sink verifies the required
scoped execution capability before allowing the consequential
operation to become effective.
The architecture prevents the automatic conversion of cryptographic
data-access authority into unrestricted network transmission, file
export, credential-mediated action, persistent-state modification,
signing, deployment, or other externally effective activity.
The system may be implemented within confidential-VM environments,
protected key-management services, HSMs, secure enclaves, host-side
credential brokers, hardware-associated execution interfaces, and
distributed protected authorization systems.
Das Expires 19 April 2027 [Page 820]
Internet-Draft Protected AI Execution Finality October 2026
11.20.2. WF-20.2 — Participating Technical Components
In one non-limiting embodiment, the system comprises:
AE-2001 — Artificial-Intelligence Execution Environment
An AI agent, model runtime, orchestration service, tool-execution
process, confidential workload, or corresponding computational
environment that may request protected cryptographic access and
generate consequential operations.
CV-2002 — Attested Confidential Execution Environment
A confidential VM, secure enclave, TEE, or other protected execution
environment providing the hardware-supported or authenticated
execution-context properties required by the applicable embodiment.
RK-2003 — Root-Key Authority
A user-controlled or user-authorized cryptographic authority
maintaining the applicable root encryption key.
DA-2004 — Data-Access Authority Store
An authenticated source of permitted user-data scopes, eligible
workloads, attestation requirements, key-use conditions, and data-
access validity state.
HA-2005 — Hardware Attestation Component
A component producing authenticated measurements of the execution
environment and applicable protected software configuration.
AV-2006 — Attestation Verification Component
A mechanism configured to verify required hardware trust, workload
identity, measurement, freshness, and policy conditions.
KD-2007 — Protected Key-Derivation Component
A cryptographic component configured to derive a bounded key from
authorized key material and appropriate derivation context.
KW-2008 — Protected Key-Wrapping Component
A mechanism configured to protect a data-access or session key for
use by an authorized recipient or protected execution context.
Das Expires 19 April 2027 [Page 821]
Internet-Draft Protected AI Execution Finality October 2026
KE-2009 — Protected Key-Enablement Gate
A mechanism configured to authorize or withhold key release, key
unwrapping, or an equivalent bounded cryptographic operation.
KS-2010 — Protected Key Store
A protected mechanism maintaining encryption keys, key references,
permitted uses, rotation versions, revocation state, and other
required key-management information.
KB-2011 — Protected Credential or Key-Use Broker
A service controlling consequential use of designated credentials,
signing keys, cryptographic service identities, or other protected
key-based authority.
IM-2012 — Candidate Act Interception Component
A component configured to intercept proposed consequential operations
before their governed effectuation boundaries.
HQ-2013 — Non-Effective Candidate Act Holding Mechanism
A queue, protected buffer, pending operation record, inactive
transmission request, or equivalent controlled staging mechanism.
DC-2014 — Candidate Act Descriptor Component
A mechanism configured to construct or verify the canonical
representation of the concrete consequential operation.
PED-2015 — Protected Enforcement Domain
A protected authority component configured to validate operation-
specific authorization independently of key-enablement success.
PS-2016 — Protected Authorization-State Store
A mechanism maintaining policy epochs, revocation state, nonce state,
usage limits, protected validation commitments, and capability-
consumption state.
EV-2017 — Protected Validation-Evidence Component
A mechanism configured to generate or commit protected evidence of
the required operation-specific authorization.
Das Expires 19 April 2027 [Page 822]
Internet-Draft Protected AI Execution Finality October 2026
CR-2018 — Scoped Execution-Capability Mechanism
A component configured to release or make available bounded authority
for a particular consequential operation.
FS-2019 — Key-Use or Credential Finality Sink
An enforcement-controlled interface governing a cryptographic action
or credential-mediated consequential effect, according to the
selected embodiment.
FS-2020 — External Effectuation Finality Sink
A protected network, service, storage, financial, deployment, or
hardware interface configured to verify the applicable operation-
specific capability before allowing the externally effective
consequence.
HF-2021 — Protected Freshness and Key-State Component
A protected mechanism maintaining key generations, usage counters,
authorization versions, hardware freshness, or other state required
for replay-resistant authorization.
RC-2022 — Protected Recovery and Reconciliation Component
A mechanism configured to restore bounded key authority and reconcile
current capability state following failure, migration, snapshot
restoration, or key rotation.
OS-2023 — Protected Operation-Outcome Store
A mechanism maintaining pending, authorized, denied, consumed,
completed, revoked, and indeterminate operation records.
The components may be implemented within one protected node or
distributed among authenticated user, cloud, hardware, and
effectuation systems.
11.20.3. WF-20.3 — Separation of Root-Key Control and AI Computation
The system establishes a trust boundary between AE-2001 and RK-2003.
The AI execution environment may request authorized access to
encrypted information.
However, it does not independently control the root encryption key or
the protected key-authority policy.
Das Expires 19 April 2027 [Page 823]
Internet-Draft Protected AI Execution Finality October 2026
The root key remains within:
(a) a user-controlled HSM;
(b) a user-authorized external key-management service;
(c) a protected user device;
(d) a secure element;
(e) a protected enterprise key authority; or
(f) another authorized cryptographic custody arrangement.
The ordinary AI workload cannot export the root key through the
permitted key-enablement interface.
A request to access encrypted data is evaluated against the
applicable authorized scope.
The requesting agent cannot expand that scope merely by selecting
another object, changing an application-level identifier, or
asserting that broader access is required.
11.20.4. WF-20.4 — Root-Key and Derived-Key Distinction
The root encryption key and a derived data-access key perform
distinguishable roles.
The root key is retained as protected key-authority material.
A derived key may be generated for a permitted data scope, workload,
session, validity interval, or cryptographic purpose.
A non-limiting representation is:
Kderived = KDF(Kroot, Context)
where:
Kderived denotes the derived key;
KDF denotes an appropriate cryptographic key-derivation function;
Kroot denotes root key material controlled by the authorized key
authority; and
Context denotes an unambiguous derivation context.
Das Expires 19 April 2027 [Page 824]
Internet-Draft Protected AI Execution Finality October 2026
The context may include:
user_authority_id;
key_version;
data_scope_id;
workload_identity;
authorized_purpose;
session_id;
policy_epoch;
derivation_domain.
The derivation function must provide the key-separation properties
required by the selected implementation.
A derived key is not assumed to be non-extractable merely because it
was generated by a KDF.
Its confidentiality depends upon how the derived key is protected,
transported, stored, and used.
11.20.5. WF-20.5 — User-Authorized Key Scope
DA-2004 maintains the applicable cryptographic data-access
authorization.
The authority may identify:
(a) protected user-data scope;
(b) eligible confidential VM;
(c) approved software measurement;
(d) permitted workload identity;
(e) key-use purpose;
(f) authorized data object or object class;
(g) key version;
Das Expires 19 April 2027 [Page 825]
Internet-Draft Protected AI Execution Finality October 2026
(h) validity interval;
(i) usage limit;
(j) required hardware attestation;
(k) user revocation state; and
(l) protected authorization epoch.
An illustrative authorization record comprises:
data_access_authority_id;
user_or_tenant_reference;
authorized_workload_id;
approved_measurement_reference;
data_scope;
permitted_key_operation;
key_version;
valid_from;
valid_until;
maximum_uses;
policy_epoch;
revocation_reference.
The protected key-enablement mechanism verifies the required
conditions before authorizing the cryptographic access operation.
11.20.6. WF-20.6 — Hardware Attestation Before Key Enablement
HA-2005 produces a cryptographically verifiable measurement of CV-
2002.
AV-2006 evaluates the attestation against the applicable approved
trust conditions.
The verification may include:
Das Expires 19 April 2027 [Page 826]
Internet-Draft Protected AI Execution Finality October 2026
(a) authenticity of the attestation report;
(b) accepted hardware trust root;
(c) confidential VM identity;
(d) workload software measurement;
(e) required security configuration;
(f) measurement freshness;
(g) authorized data-access scope; and
(h) applicable policy and revocation state.
An illustrative predicate is:
Vattest =
AuthenticReport AND
ApprovedMeasurement AND
CorrectWorkload AND
ValidConfiguration AND
FreshAttestation
Where any mandatory predicate fails, the protected key-enablement
mechanism withholds the corresponding bounded key access.
Hardware attestation does not independently establish that every
later operation generated by the attested workload is authorized.
11.20.7. WF-20.7 — Protected Key-Enablement Decision
KE-2009 evaluates the key-access authority associated with a
particular request.
An illustrative predicate is:
Vkey =
Vattest AND
UserAuthorityValid AND
Das Expires 19 April 2027 [Page 827]
Internet-Draft Protected AI Execution Finality October 2026
DataScopeValid AND
KeyPurposeValid AND
ProtectedStateValid
where:
Vkey denotes the protected key-enablement result;
Vattest denotes required attestation validity;
UserAuthorityValid verifies the corresponding user-controlled or
user-authorized key authority;
DataScopeValid verifies permitted protected information;
KeyPurposeValid verifies the authorized cryptographic operation; and
ProtectedStateValid verifies applicable freshness, revocation, usage,
and protected-state conditions.
If Vkey succeeds, the protected system may provide the permitted
derived key, wrapped key, session-limited key, or bounded
cryptographic operation.
If Vkey fails, the requested key-enablement operation is withheld.
Successful Vkey does not imply that a later consequential Candidate
Act is authorized.
11.20.8. WF-20.8 — Derived-Key Release
In one implementation, KD-2007 derives a key limited by the
applicable authorized context.
The resulting key may be made available only inside an attested
confidential execution environment.
The system may restrict:
(a) permitted data class;
(b) cryptographic purpose;
(c) associated workload;
(d) session lifetime;
Das Expires 19 April 2027 [Page 828]
Internet-Draft Protected AI Execution Finality October 2026
(e) key version;
(f) protected authorization epoch; or
(g) other applicable conditions.
The implementation may use secure key import, protected memory,
enclave-bound key provisioning, or equivalent controls.
Where the derived key is exported into ordinary process memory, the
system must account for the possibility that the process can copy or
misuse it.
Strong non-extractability requires an appropriate technical mechanism
rather than a policy statement alone.
11.20.9. WF-20.9 — Wrapped-Key Enablement
In another implementation, KW-2008 produces a wrapped key.
A non-limiting expression is:
Wkey = KeyWrap(Ktransport, Kdata, AssociatedContext)
where:
Wkey denotes the wrapped key representation;
Ktransport denotes the protected key-encryption or wrapping key;
Kdata denotes the bounded data-access key; and
AssociatedContext denotes authenticated key-use context where
supported by the selected wrapping construction.
The receiving protected component verifies the required authorization
before unwrapping or importing the key.
The wrapping procedure prevents unauthorized disclosure of key
material in transit under the selected cryptographic assumptions.
However, wrapping alone does not enforce the permitted destination,
operation, or effectuation scope after the key becomes available.
The corresponding access-control or Finality Sink mechanism must
enforce those separate requirements.
Das Expires 19 April 2027 [Page 829]
Internet-Draft Protected AI Execution Finality October 2026
11.20.10. WF-20.10 — Session-Limited Key Enablement
A bounded key may be associated with an authenticated execution
session.
An illustrative session record comprises:
session_id;
attested_vm_identity;
workload_identity;
approved_measurement;
data_scope;
key_version;
validity_interval;
policy_epoch;
revocation_epoch;
key_usage_state.
The protected component verifies that the current session satisfies
the required conditions before performing the authorized
cryptographic operation.
An expired, revoked, or incompatible session does not retain
authority merely because an earlier key-release request succeeded.
Where keys are already resident inside a running workload, revocation
of future key issuance does not by itself prove the resident key has
become unusable.
The implementation must use protected key-use controls, key
retirement, session teardown, or another effective enforcement
mechanism to provide stronger revocation guarantees.
11.20.11. WF-20.11 — Bounded Cryptographic Operation Without Key Export
In an alternative implementation, the AI workload never receives
reusable key material.
Das Expires 19 April 2027 [Page 830]
Internet-Draft Protected AI Execution Finality October 2026
Instead, it submits a cryptographic operation request to a protected
key service.
The request may seek:
(a) decryption of an authorized object;
(b) authentication of a permitted message;
(c) signing of an approved artifact;
(d) protected credential application;
(e) unwrapping of a bounded key; or
(f) another permitted cryptographic operation.
The protected key service evaluates the applicable key-use
conditions.
Where the cryptographic operation itself is consequential, the
operation is also subjected to the required execution-finality
authorization before its effectuation.
A service providing bounded decryption is not automatically
authorized to sign, transmit, or publish the resulting plaintext.
11.20.12. WF-20.12 — Cryptographic Access Is Not External Execution
Authority
The architecture establishes separate authorization conditions:
Vdata governs protected data or key access.
Veffect governs the externally effective Candidate Act.
An illustrative relationship is:
DataAccessAllowed = Vdata
EffectuationAllowed = Veffect
The architecture does not assume:
Vdata implies Veffect.
For example, an agent may obtain a bounded decryption key to read a
user document.
Das Expires 19 April 2027 [Page 831]
Internet-Draft Protected AI Execution Finality October 2026
That authorization does not automatically permit the agent to export
the document.
Similarly, an agent may be permitted to read a connected-service
credential reference without acquiring permission to apply the
credential to a different API operation.
The protected external effect remains subject to operation-specific
validation and Finality Sink verification.
11.20.13. WF-20.13 — Candidate Cryptographic Operation
Where the key-use operation itself creates a governed consequential
effect, the system classifies it as a Candidate Act.
Examples include:
(a) production artifact signing;
(b) protected credential application;
(c) release of a confidential encryption key to another domain;
(d) creation of a cryptographically effective authorization token;
(e) signing of a payment instruction;
(f) activation of a protected service identity; or
(g) another consequential protected key operation.
A request merely to perform a permitted bounded decryption for
internal computation may be governed by the data-access authorization
alone where no separate execution-finality requirement applies.
The applicable claim and selected security boundary determine whether
a given cryptographic operation requires its own Candidate Act
authorization.
The system does not automatically classify every internal
cryptographic calculation as an external effect.
11.20.14. WF-20.14 — Interception of the Consequential Operation
AE-2001 prepares a proposed consequential operation involving
protected information or cryptographic authority.
IM-2012 intercepts the operation before the applicable Finality Sink.
Das Expires 19 April 2027 [Page 832]
Internet-Draft Protected AI Execution Finality October 2026
HQ-2013 maintains the corresponding Candidate Act in a Non-Effective
State.
A representative staging record comprises:
candidate_act_id;
requesting_workload_id;
cryptographic_access_reference;
requested_operation;
target_resource;
destination;
payload_reference;
key_scope_reference;
policy_epoch;
finality_sink_id;
status = NON_EFFECTIVE.
The proposed operation remains pending until the protected execution-
finality conditions succeed.
The previous key-release decision does not independently advance the
Candidate Act into an effective state.
11.20.15. WF-20.15 — Candidate Act Descriptor Formation
DC-2014 constructs a machine-readable descriptor representing the
concrete consequential operation.
An illustrative descriptor comprises:
candidate_act_id;
attested_vm_identity;
workload_identity;
data_access_authority_reference;
Das Expires 19 April 2027 [Page 833]
Internet-Draft Protected AI Execution Finality October 2026
key_scope_reference;
requested_operation_class;
actual_destination;
resource_identifier;
payload_digest;
credential_or_key_usage_class;
user_execution_scope;
policy_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_id.
Only the applicable mandatory fields are included in the protected
authorization decision.
The descriptor binds the operation to its effectuation context.
The protected system does not treat a valid key identifier as a
complete substitute for the Candidate Act Descriptor.
11.20.16. WF-20.16 — Canonical Candidate Act Representation
An illustrative canonical representation is:
Dkeyact = Canon_v(W, KEY_SCOPE, ACT, TARGET, PARAM, AUTH, EPOCH,
SINK)
where:
Dkeyact denotes the Candidate Act Descriptor;
W denotes authenticated workload context;
KEY_SCOPE denotes the associated cryptographic-access scope;
ACT denotes the proposed consequential operation;
Das Expires 19 April 2027 [Page 834]
Internet-Draft Protected AI Execution Finality October 2026
TARGET denotes the destination or protected resource;
PARAM denotes the effectuation-relevant parameters;
AUTH denotes applicable user and operation authority references;
EPOCH denotes required policy and authorization-state versions; and
SINK denotes the designated Finality Sink.
An illustrative digest is:
hKeyAct = H("DAS-KEY-EFFECTUATION-v1" || Encode(Dkeyact))
The selected encoding must preserve distinctions required by the
authorization.
A digest binding does not eliminate the need to verify the actual
operation parameters at the applicable effectuation boundary.
11.20.17. WF-20.17 — Protected Operation-Specific Authority
PED-2015 obtains the Authority Object applicable to the proposed
operation.
The authority may specify:
(a) eligible workload identity;
(b) authorized operation class;
(c) permitted key-use purpose;
(d) permitted destination;
(e) applicable tenant or user scope;
(f) approved credential use;
(g) required confidential-VM attestation;
(h) approved policy epoch;
(i) nonce or capability usage limits;
(j) revocation state;
(k) protected execution context; and
Das Expires 19 April 2027 [Page 835]
Internet-Draft Protected AI Execution Finality October 2026
(l) designated Finality Sink.
The PED validates the operation independently of the earlier key-
access decision.
A valid data-access grant may satisfy one contextual predicate.
It does not override a failed operation-specific authority predicate.
11.20.18. WF-20.18 — Operation-Specific Authorization Predicate
An illustrative protected authorization expression is:
Veffect =
Poperation AND
Pscope AND
Pdestination AND
Pcontext AND
Pstate AND
Psink
where:
Veffect denotes the operation-specific authorization result;
Poperation verifies the requested consequential operation;
Pscope verifies user and key-use scope;
Pdestination verifies the actual destination or recipient;
Pcontext verifies required attestation or workload context;
Pstate verifies policy, revocation, freshness, and protected usage
state; and
Psink verifies the designated Finality Sink.
Where a cryptographic key is required for the effect, the PED may
additionally verify the associated key-access authority.
Das Expires 19 April 2027 [Page 836]
Internet-Draft Protected AI Execution Finality October 2026
Failure of any mandatory predicate prevents release of the
corresponding execution capability.
11.20.19. WF-20.19 — Protected State Transition
Following successful protected validation, PED-2015 performs the
required authorization-state operation.
The operation may comprise:
(a) reserving a single-use key-effectuation grant;
(b) consuming or registering a nonce;
(c) verifying current key and policy epochs;
(d) checking revocation state;
(e) registering the Candidate Act digest;
(f) reserving a bounded capability identifier;
(g) updating a protected usage allowance; or
(h) recording the intended Finality Sink.
The required state transition is controlled by PS-2016.
Where a single-use grant is required, incompatible concurrent
attempts cannot independently consume the same authorization.
A failed required state transition prevents successful execution-
capability availability.
11.20.20. WF-20.20 — Protected Validation-Evidence Commitment
EV-2017 generates or commits protected evidence associated with the
Candidate Act.
An illustrative record comprises:
receipt_id;
candidate_act_id;
candidate_act_digest;
attested_workload_reference;
Das Expires 19 April 2027 [Page 837]
Internet-Draft Protected AI Execution Finality October 2026
authorized_key_scope;
operation_authority_reference;
protected_state_transition;
policy_epoch;
nonce;
finality_sink_id;
decision;
protected_authentication.
Where enforcement point 84 and its selected execution-finality
embodiment apply, the protected validation evidence is committed
before, or atomically with, release of the operation-specific
execution capability.
The record is not merely an after-the-fact logging artifact.
An ordinary key-management audit entry does not independently
establish that the concrete external operation satisfied all required
finality predicates.
11.20.21. WF-20.21 — Operation-Specific Execution Capability
CR-2018 makes available the bounded execution capability following
successful protected authorization.
An illustrative capability contains or references:
capability_id;
candidate_act_digest;
authorized_operation;
workload_identity;
attested_vm_reference;
user_execution_scope;
key_usage_scope;
Das Expires 19 April 2027 [Page 838]
Internet-Draft Protected AI Execution Finality October 2026
destination;
policy_epoch;
revocation_epoch;
nonce;
expiry;
usage_limit;
validation_receipt_digest;
finality_sink_id.
A non-limiting cryptographic representation is:
Ckeyact = Sign_skPED(Encode(hKeyAct, hReceipt, Scope, VM, Epoch,
Nonce, Expiry, Sink))
The particular capability format may comprise a signed artifact, MAC-
authenticated permit, sealed handle, protected state-table entry, or
authenticated hardware-enablement condition.
The capability does not become a general bearer credential merely
because it can be transported between components.
The Finality Sink enforces the required operation, state, context,
usage, and sink bindings.
11.20.22. WF-20.22 — Protected Key-Use Finality Sink
FS-2019 may control a consequential cryptographic operation.
Examples include:
(a) use of a production signing key;
(b) application of a protected service credential;
(c) a bounded key-unwrapping operation;
(d) release of key material across a protected domain boundary;
(e) generation of an authenticated production artifact; or
(f) issuance of a credential-dependent external instruction.
Das Expires 19 April 2027 [Page 839]
Internet-Draft Protected AI Execution Finality October 2026
The protected key-use Finality Sink verifies the corresponding
operation-specific authorization before permitting the governed
cryptographic effect.
A key residing inside an HSM does not independently provide such
finality control if an authorized caller can use the key without
satisfying the required Candidate Act-specific predicates.
11.20.23. WF-20.23 — External Effectuation Finality Sink
FS-2020 controls the downstream consequential effect.
The interface may comprise:
(a) a network egress controller;
(b) an API gateway;
(c) a credential broker;
(d) a file-export interface;
(e) a storage-commit service;
(f) a payment or transaction interface;
(g) a deployment controller;
(h) a SmartNIC or DPU enforcement component; or
(i) another protected effectuation boundary.
The Finality Sink reconstructs or verifies the actual operation.
It checks the execution capability and required protected state
immediately before permitting the governed effect.
An earlier decryption operation or cryptographic key-use approval
does not independently replace the Finality Sink verification.
11.20.24. WF-20.24 — Relationship Between Key-Use and External Finality
The architecture may have one or two separately governed
consequential boundaries.
In a first implementation, an authenticated key-use operation is the
governed effect, and FS-2019 performs the required finality
verification.
Das Expires 19 April 2027 [Page 840]
Internet-Draft Protected AI Execution Finality October 2026
In a second implementation, a protected key-use operation is an
intermediate stage, while the actual external transmission,
transaction, or storage modification is separately governed at FS-
2020.
In a third implementation, both key use and downstream effectuation
require distinct bounded authorizations.
The selected claim and Authority Object determine which structure is
mandatory.
The system does not automatically assume that authorizing protected
credential application also authorizes any later independently
governed downstream operation.
Where both boundaries are required, each applies its own
effectuation-specific verification.
11.20.25. WF-20.25 — Governance-Key Isolation
In the related embodiment corresponding to enforcement point 81,
cryptographic key material used for protected governance or
execution-capability issuance remains within a protected governance
boundary.
The AI compute process communicates with the governance component
through an authenticated interface.
The process cannot obtain unrestricted access to the governance key.
The protected component may use such key material to authenticate an
operation-scoped execution capability only after required protected
validation.
The system distinguishes governance signing keys from user-data
encryption keys.
The two key classes may have different owners, purposes, rotation
procedures, authorization conditions, and security boundaries.
A valid user-data key is not thereby a valid governance capability-
issuance key.
11.20.26. WF-20.26 — Attestation-Dependent Governance Key Use
Where governance key use depends upon a confidential governance-node
attestation, the protected issuance procedure verifies the required
attestation state.
Das Expires 19 April 2027 [Page 841]
Internet-Draft Protected AI Execution Finality October 2026
Applicable conditions may include:
(a) registered governance identity;
(b) approved launch measurement;
(c) approved firmware measurement;
(d) protected software configuration;
(e) policy version;
(f) attestation freshness; and
(g) revocation state.
If a required governance-node measurement becomes invalid, the
corresponding protected component refuses further dependent
capability issuance until successful revalidation.
This issuance restriction is distinguishable from revocation of
already issued capabilities.
Where outstanding capabilities must also become invalid, the
applicable Finality Sink must enforce the required current
governance-state or revocation condition.
11.20.27. WF-20.27 — Hardware-Freshness Binding
In the related embodiment corresponding to enforcement point 83,
execution capability validity may depend upon hardware-freshness
state.
The state may comprise:
(a) trusted monotonic counter;
(b) secure boot epoch;
(c) protected clock;
(d) device sequence; or
(e) hardware-attested nonce.
The protected authority binds the applicable state to the issued
capability.
Das Expires 19 April 2027 [Page 842]
Internet-Draft Protected AI Execution Finality October 2026
The designated Finality Sink verifies the mandatory freshness
condition before effectuation.
Restoration or replay of previously valid authorization material
fails when the current protected hardware state no longer corresponds
to the capability.
A freshness value stored only within rollback-accessible guest memory
does not independently establish rollback resistance.
11.20.28. WF-20.28 — Revocation of Data-Access Keys
The user or authorized root-key authority may revoke future protected
data-access authorization.
The protected key-enablement component verifies the current
applicable revocation state before enabling affected new key
operations.
Revocation may prevent:
(a) further derived-key issuance;
(b) additional key unwrapping;
(c) new session-key enablement;
(d) new protected decryption operations; or
(e) other key-use operations still subject to the protected
enforcement boundary.
If plaintext or reusable key material was previously exported into
ordinary workload memory, the key authority cannot assume that
revocation retroactively erases all copies.
Stronger revocation requires technical control of the retained key
material or the relevant cryptographic operation.
11.20.29. WF-20.29 — Revocation of External Execution Authority
Operation-specific execution authorization is separately revocable.
A valid data-access key may remain available while the protected
authority revokes permission to perform a particular external
operation.
Das Expires 19 April 2027 [Page 843]
Internet-Draft Protected AI Execution Finality October 2026
The Finality Sink enforces the required current revocation and policy
conditions.
For example, an agent may continue reading an authorized private
document while being prohibited from transmitting its contents to a
newly revoked destination.
The external effect remains blocked even if the underlying document
is decryptable.
This illustrates the independence of key-access authority and
effectuation authority.
11.20.30. WF-20.30 — Key Rotation and Version Continuity
The root-key or data-access key authority may rotate protected key
material.
A protected key-version record may comprise:
key_id;
key_version;
authorized_data_scope;
valid_from;
valid_until;
revocation_state;
wrapping_reference;
protected_authority_generation.
The protected system verifies the key version applicable to the
encrypted data and the authorized access request.
A changed key version does not automatically invalidate every
separately governed execution capability unless the key version is a
mandatory binding or the protected policy requires that result.
Likewise, successful key rotation does not restore consumed execution
authorization.
Key lifecycle and operation-capability lifecycle remain separately
governed.
Das Expires 19 April 2027 [Page 844]
Internet-Draft Protected AI Execution Finality October 2026
11.20.31. WF-20.31 — Snapshot and Backup Recovery
The system may restore an encrypted confidential VM backup, agent-
memory snapshot, or recovered execution instance.
The restored environment must reestablish the attestation and user-
authorized data-access conditions required by its current protected
policy.
The recovery procedure may include:
(a) fresh confidential-VM attestation;
(b) workload identity verification;
(c) user-authorized key-access validation;
(d) appropriate bounded key rederivation or unwrapping;
(e) current key-version verification;
(f) protected policy and revocation checks;
(g) authoritative execution-capability state reconciliation; and
(h) identification of pending and previously attempted operations.
Restoring an encrypted VM image does not automatically restore
previously consumed, expired, or revoked execution capabilities.
The authoritative protected consumption and revocation state remains
separate from rollback-accessible backup contents.
11.20.32. WF-20.32 — Key-State and Capability-State Separation
The architecture maintains separate protected state for key access
and execution authority where required.
A non-limiting key-access state comprises:
key_authority_id;
key_version;
data_scope;
authorized_workload;
Das Expires 19 April 2027 [Page 845]
Internet-Draft Protected AI Execution Finality October 2026
attestation_reference;
validity_interval;
key_usage_status.
A non-limiting execution state comprises:
candidate_act_id;
execution_capability_id;
authorized_operation;
finality_sink_id;
policy_epoch;
nonce;
capability_consumption_status;
effectuation_outcome.
The two state mechanisms may reside in one protected service, but
their authorization semantics remain distinct.
Restoration of a key-access session does not automatically restore an
earlier execution-capability usage allowance.
11.20.33. WF-20.33 — Crash Between Authorization and Effectuation
The system distinguishes failures occurring at different stages.
Failure before attestation validation: The protected key-enablement
operation is refused when required attestation cannot be established.
Failure after attestation but before key enablement: The system
verifies current authority before any renewed key operation.
Failure after data decryption but before Candidate Act validation:
The external operation remains non-effective.
Failure during protected state or evidence commitment: No valid
corresponding execution capability becomes available when a mandatory
commitment has failed.
Das Expires 19 April 2027 [Page 846]
Internet-Draft Protected AI Execution Finality October 2026
Failure after capability release but before Finality Sink
verification: The Finality Sink verifies current state before
permitting effectuation.
Failure after possible remote effectuation: The operation may remain
indeterminate until reliable completion evidence is available.
Failure after VM snapshot restoration: Current protected key and
execution state are independently reconciled.
An indeterminate effect is not automatically repeated merely because
the AI workload was restarted.
11.20.34. WF-20.34 — Illustrative User-Controlled Encrypted Data Access
A user maintains encrypted enterprise documents under a user-
controlled root-key authority.
An AI agent executes inside a confidential VM.
The agent requests bounded access to a specified document.
The confidential VM supplies the required hardware attestation.
The protected key authority verifies the VM identity, workload
measurement, authorized data scope, freshness, and current data-
access policy.
A derived or wrapped data-access key becomes available within the
permitted protected context.
The agent decrypts the document and performs the authorized internal
computation.
The agent subsequently prepares an external network request
containing protected information.
The request is classified as a Candidate Act and held in a Non-
Effective State.
The PED validates the concrete operation, recipient, purpose,
protected scope, policy state, and intended network Finality Sink.
Required validation evidence is committed, and the appropriate scoped
execution capability becomes available.
The network Finality Sink verifies the actual request and capability.
Das Expires 19 April 2027 [Page 847]
Internet-Draft Protected AI Execution Finality October 2026
If the proposed external transmission is not authorized, the request
remains blocked despite successful decryption.
11.20.35. WF-20.35 — Illustrative Protected Credential Broker
An AI agent prepares an operation requiring a protected service
credential.
The credential is held by a protected credential broker rather than
exposed for unrestricted use by the agent.
The agent submits a proposed operation identifying:
(a) requested service;
(b) operation class;
(c) destination;
(d) parameters;
(e) authorized purpose; and
(f) required credential scope.
The corresponding operation is treated as a Candidate Act.
PED-2015 validates the applicable Authority Object and operation
context.
The protected system commits required validation evidence and
releases an act-scoped capability.
KB-2011 or the appropriate Finality Sink verifies the capability
before applying the protected credential.
Where a separate downstream effectuation boundary is governed, that
boundary independently verifies its applicable authorization.
The agent cannot convert knowledge of a credential reference into
unrestricted permission to use the underlying service identity.
11.20.36. WF-20.36 — Illustrative Signing-Key Finality
An autonomous coding agent generates an executable artifact.
A production signing key is maintained within a protected HSM or
governance service.
Das Expires 19 April 2027 [Page 848]
Internet-Draft Protected AI Execution Finality October 2026
The agent requests signing of the artifact.
The request is classified as a consequential Candidate Act where
protected production signing is the governed effect.
The Candidate Act Descriptor identifies the artifact digest, key-use
purpose, permitted signing identity, policy epoch, nonce, and signing
Finality Sink.
The PED validates the corresponding authorization.
Required protected state and evidence operations are completed.
A scoped signing capability becomes available.
The protected signing interface verifies the capability against the
actual artifact and authorized key-use context.
Only the permitted signature operation is performed.
Possession of the artifact, a key identifier, or ordinary access to
the signing-service interface does not independently authorize
production signing.
11.20.37. WF-20.37 — Illustrative Snapshot Replay
An AI agent obtains a valid data-access key inside a confidential VM.
It also receives a single-use execution capability permitting one
protected external operation.
The Finality Sink verifies and consumes the execution capability.
An earlier VM snapshot is then restored.
The restored workload may contain its earlier data-access session and
a copy or reference to the consumed execution capability.
The key authority applies the current attestation, key-version, and
data-access conditions.
Separately, the Finality Sink consults current protected capability-
consumption state.
The previously consumed execution capability remains invalid.
The restored VM cannot reuse the capability merely because its guest
memory represents an earlier authorization state.
Das Expires 19 April 2027 [Page 849]
Internet-Draft Protected AI Execution Finality October 2026
11.20.38. WF-20.38 — Alternative Technical Implementations
User-controlled HSM: Root-key material remains in user-controlled
hardware while bounded data-access keys are made available to
attested workloads.
External key-authority service: A user-authorized key service
provides derived, wrapped, or session-limited key access.
Confidential-VM implementation: Protected data is decrypted only
within an attested confidential execution environment.
Remote cryptographic-operation implementation: The protected key
never leaves the key service; the service performs only authorized
cryptographic operations.
Protected credential-broker implementation: Credential application
remains dependent upon operation-specific capability verification.
Protected signing implementation: An HSM verifies act-bound authority
before performing production signing.
SmartNIC or DPU implementation: A separate protected hardware
Finality Sink controls external network transmission after
cryptographic authorization.
Single-node implementation: Key access, protected authorization, and
Finality Sink functions operate within one protected node while
retaining their separate required checks.
Distributed implementation: User root-key authority, confidential VM,
PED, key-use broker, and external Finality Sink operate across
authenticated services.
Rollback-resistant implementation: Required capability-consumption
and nonce state remains outside the snapshot-restorable workload.
Different implementations provide different confidentiality, key-
extraction resistance, revocation, and effectuation guarantees.
The particular security properties depend upon the implemented trust
boundaries.
11.20.39. WF-20.39 — Failure and Fail-Closed Conditions
The system withholds the corresponding protected operation when a
mandatory condition is absent, invalid, expired, revoked,
inconsistent, replayed, or unverifiable.
Das Expires 19 April 2027 [Page 850]
Internet-Draft Protected AI Execution Finality October 2026
Non-limiting conditions include:
(a) invalid root-key authority;
(b) missing user data-access permission;
(c) unapproved confidential-VM measurement;
(d) invalid attestation;
(e) workload identity mismatch;
(f) unauthorized data scope;
(g) invalid key purpose;
(h) expired data-access authorization;
(i) revoked key version;
(j) invalid key-wrap authentication;
(k) unauthorized key export;
(l) prohibited cryptographic operation;
(m) missing Candidate Act Descriptor;
(n) unauthorized external operation;
(o) destination mismatch;
(p) invalid operation-specific Authority Object;
(q) failed protected-state transition;
(r) failed required evidence commitment;
(s) missing execution capability;
(t) capability authentication failure;
(u) policy epoch mismatch;
(v) invalid nonce;
(w) consumed or revoked capability;
Das Expires 19 April 2027 [Page 851]
Internet-Draft Protected AI Execution Finality October 2026
(x) Finality Sink mismatch;
(y) invalid governance-node attestation;
(z) hardware-freshness mismatch; or
(aa) unavailable mandatory protected verification.
Failure of key authorization does not create execution authority.
Failure of execution authorization does not authorize an unrestricted
cryptographic fallback.
11.20.40. WF-20.40 — PHOSITA Verification and Negative Tests
A person having ordinary skill in confidential computing, key
management, HSM architecture, applied cryptography, credential
security, cloud AI infrastructure, and protected execution may verify
the following.
Test 1 — Authorized derived key: Supply valid attestation and data-
access authority. Confirm bounded derived-key availability.
Test 2 — Invalid attestation: Present an unapproved VM measurement.
Key enablement is refused.
Test 3 — Wrong workload: Attempt key access from another workload.
Required workload binding fails.
Test 4 — Unauthorized data scope: Request a protected object outside
the permitted scope. Key access is denied.
Test 5 — Root-key export: Attempt unrestricted extraction of the
user-controlled root key through the agent interface. The protected
boundary refuses the operation.
Test 6 — Wrapped-key substitution: Replace the wrapped key or
required authenticated context. Protected unwrapping fails.
Test 7 — Key-purpose mismatch: Attempt a signing operation using
authority permitted only for data decryption. The applicable key-use
control refuses it.
Test 8 — Expired session: Present an expired session-limited key
authorization. New protected key enablement is denied.
Das Expires 19 April 2027 [Page 852]
Internet-Draft Protected AI Execution Finality October 2026
Test 9 — Key revocation: Revoke an applicable key-access
authorization. Further affected protected cryptographic operations
are refused.
Test 10 — Valid decryption without effectuation: Successfully decrypt
authorized data, then attempt external transmission without an
execution capability. The Finality Sink refuses the transmission.
Test 11 — Unauthorized destination: Obtain valid data access and
request an effect outside the permitted destination scope. Operation
authorization fails.
Test 12 — Candidate Act substitution: Validate one concrete operation
and present different mandatory parameters. The Finality Sink
rejects the mismatch.
Test 13 — Credential misuse: Attempt credential application outside
the approved operation. The protected credential Finality Sink
refuses it.
Test 14 — Unauthorized signing: Request protected signing of an
artifact not associated with the approved capability. The signing
operation is denied.
Test 15 — Missing validation evidence: Interrupt a mandatory
protected evidence-commitment operation. No valid corresponding
execution capability becomes available.
Test 16 — Wrong Finality Sink: Present an operation-specific
capability at another unauthorized effectuation interface. Required
sink binding fails.
Test 17 — Capability replay: Reuse a consumed single-use execution
capability. The protected state mechanism refuses reuse.
Test 18 — Concurrent consumption: Submit competing operations against
one restricted capability. Protected state prevents unauthorized
duplicate consumption.
Test 19 — Key rotation: Rotate the root or derived-key version and
verify enforcement of applicable key-version conditions.
Test 20 — Snapshot restoration: Restore an earlier confidential VM
snapshot containing a previously consumed capability. Current
protected capability state refuses replay.
Das Expires 19 April 2027 [Page 853]
Internet-Draft Protected AI Execution Finality October 2026
Test 21 — Governance-key isolation: Attempt unrestricted governance
signing-key access from the AI process. The protected boundary
refuses access.
Test 22 — Invalid governance attestation: Alter a mandatory
governance-node measurement. Dependent capability issuance is
refused pending revalidation.
Test 23 — Hardware freshness: Replay authorization under an
incompatible protected hardware generation. Required freshness
verification fails.
Test 24 — Receipt privacy: Verify enforcement evidence without
disclosure of designated plaintext or root-key material.
Test 25 — Crash after possible effect: Interrupt a credential-
mediated operation after possible execution. Recovery preserves
confirmed or indeterminate outcome state.
Test 26 — Separate protected boundaries: Verify that valid key access
does not bypass a separately required network, credential, storage,
or payment Finality Sink.
Test 27 — Alternative execution path: Attempt the governed
consequence through an interface bypassing ordinary key-access
checks. the specified finality architecture blocks or equivalently
mediates the effectuation path.
Test 28 — Independent key and execution revocation: Revoke execution
authority while leaving data-access authority valid. Confirm that
decryption remains governed by its policy but the unauthorized
external effect is withheld.
Test 29 — Single-node implementation: Verify independent key-enable
and act-effectuation predicates within one protected controller.
Test 30 — Distributed implementation: Verify authenticated state,
key-use authority, and operation-specific Finality Sink
correspondence across separate protected components.
11.20.41. WF-20.41 — Claim-Specific Technical Support
Enforcement Point 84 — User-Controlled Confidential VM with
Cryptographically Bound Execution Authority
Das Expires 19 April 2027 [Page 854]
Internet-Draft Protected AI Execution Finality October 2026
WF-20.3 through WF-20.24 describe protected data encryption,
confidential-VM attestation, bounded key enablement, independent
Candidate Act authorization, required evidence commitment, and
separate Finality Sink verification.
Enforcement Point 85 — User-Held Root-Key and Attested Derived-Key
Release
WF-20.4 through WF-20.11 describe root-key custody, derived and
wrapped key access, session limits, authorized data scopes, workload
identity, attestation predicates, and avoidance of unrestricted root-
key disclosure.
Enforcement Point 86 — Dual Authorization for Decryption and External
Effect
WF-20.12 through WF-20.24 describe separate data-access and external-
effect authorization states and independent downstream capability
verification.
Enforcement Point 87 — Cryptographic Binding of Confidential-VM State
to Candidate Act
WF-20.15, WF-20.16, WF-20.21, and WF-20.23 describe binding the
capability to the Candidate Act, attested execution state, authorized
scope, policy epoch, nonce, and Finality Sink.
Enforcement Point 88 — Privacy-Preserving Execution Evidence
WF-20.20 and WF-20.24, together with WF-20.38, address authenticated
evidence and privacy-preserving verification arrangements. The
complete evidence-record specification remains in WF-19.25 through
WF-19.27.
Enforcement Point 89 — Confidential-VM Recovery and Key-State
Continuity
WF-20.30 through WF-20.33 describe fresh attestation, bounded key
reenablement, protected capability-state reconciliation, and replay
prevention after restoration.
Enforcement Point 79 — Confidential Governance VM and Hardware-
Attested SmartNIC Finality
WF-20.25 through WF-20.27 provide the related governance-key,
attestation, hardware freshness, and protected issuer conditions.
The complete SmartNIC/DPU effectuation workflow remains in WF-18.
Das Expires 19 April 2027 [Page 855]
Internet-Draft Protected AI Execution Finality October 2026
Enforcement Point 80 — Confidential VM Attestation Object
WF-20.26 uses the applicable authenticated governance measurement,
with the complete attestation-object construction and verification in
WF-18.
Enforcement Point 81 — Confidential Governance-Key Isolation
WF-20.25 describes protected governance key custody and controlled
capability issuance without unrestricted key access by the ordinary
AI compute process.
Enforcement Point 82 — Attestation Change Disables Capability
Issuance
WF-20.26 distinguishes invalid governance measurement, denial of
further dependent capability issuance, and independent revocation
checks for outstanding capabilities.
Enforcement Point 83 — Cryptographically Bound Hardware Freshness
WF-20.27 describes hardware-freshness binding and rejection of replay
when the current protected hardware state does not satisfy the
applicable capability.
11.20.42. WF-20.42 — Technical Effect
The workflow establishes distinct protected authorization
dependencies for cryptographic access and consequential execution.
The operative sequence comprises:
(a) user or user-authorized root-key control;
(b) encryption of protected information;
(c) authenticated confidential-workload attestation;
(d) verification of bounded user-data access;
(e) derived, wrapped, session-limited, or protected-operation key
enablement;
(f) authorized internal use of protected data;
(g) generation of a consequential Candidate Act;
(h) mandatory interception and Non-Effective State holding;
Das Expires 19 April 2027 [Page 856]
Internet-Draft Protected AI Execution Finality October 2026
(i) construction of an operation-specific descriptor;
(j) independent protected execution-authority validation;
(k) required protected-state handling;
(l) protected validation-evidence commitment;
(m) release of a scoped execution capability;
(n) independent verification at the appropriate key-use or external-
effectuation Finality Sink;
(o) controlled effectuation or fail-closed refusal; and
(p) protected revocation, consumption, freshness, and recovery state.
The architecture prevents a requesting AI workload from treating
possession of a valid decryption key, successful data access, access
to a protected signing endpoint, or an authenticated credential
reference as unrestricted authority to perform an externally
effective operation.
The protected key-enable component controls whether the specified
cryptographic access is permitted.
The Protected Enforcement Domain controls whether the concrete
consequential operation is authorized.
The Finality Sink enforces the corresponding execution capability at
the actual governed effectuation boundary.
Computation is not authority to act.
A decryption key is not an execution capability.
Permission to decrypt is not permission to disclose.
Possession of a signing key reference is not permission to sign any
artifact.
A protected credential is not unrestricted authority to use the
corresponding service.
Key enablement and final effectuation remain independently governed
where required.
Das Expires 19 April 2027 [Page 857]
Internet-Draft Protected AI Execution Finality October 2026
11.21. WF-21 — Hardware Finality Latch, NIC/SmartNIC/DPU Enforcement,
Protected DMA and Network Admission, Capability-Dependent
Hardware Effectuation, and Fail-Closed Revocation
11.21.1. WF-21.1 — Technical Purpose
This embodiment describes a computer-implemented hardware-assisted
protected execution-finality architecture for controlling
consequential operations generated by artificial-intelligence agents,
autonomous workloads, accelerator-based computations, or associated
execution environments.
The system establishes a protected enforcement dependency between the
authority to perform a consequential operation and the hardware
interface capable of making that operation effective.
A proposed consequential operation is classified as a Candidate Act.
The Candidate Act remains in a Non-Effective State until the
applicable Protected Enforcement Domain validates the required
operation-specific authorization conditions, completes mandatory
protected-state and evidence-commitment operations, and releases or
makes available a scoped execution capability.
A hardware-associated Finality Sink verifies the capability against
the actual operation and its required authorization state before
permitting the operation to cross its designated execution-finality
boundary.
The hardware implementation may control:
(a) network packet transmission;
(b) DMA or RDMA admission;
(c) accelerator-to-host data export;
(d) accelerator-to-accelerator transfers;
(e) fabric-switch forwarding;
(f) protected memory access;
(g) credential-mediated transmission;
(h) storage-controller commitment;
(i) device-control commands;
Das Expires 19 April 2027 [Page 858]
Internet-Draft Protected AI Execution Finality October 2026
(j) optical-path enablement; or
(k) another consequential operation crossing a hardware-controlled
boundary.
The Hardware Finality Latch remains disabled or non-admitting until
the required capability-dependent verification succeeds.
The architecture distinguishes ordinary hardware connectivity,
trusted computation, hardware attestation, authorization of a
particular Candidate Act, and final hardware effectuation.
The fact that a workload can generate a packet, DMA descriptor, tool
command, or accelerator output does not independently confer
authority to deliver it through the governed hardware interface.
11.21.2. WF-21.2 — Participating Technical Components
In one non-limiting implementation, the system comprises:
AE-2101 — Artificial-Intelligence Compute Environment
An AI agent, model runtime, accelerator workload, GPU server,
autonomous process, or corresponding component configured to produce
a proposed consequential operation.
CI-2102 — Candidate Act Interception Component
A mandatory software, firmware, hypervisor, kernel, or hardware-
associated mechanism configured to intercept the proposed operation
before the governed effect.
HQ-2103 — Non-Effective Operation Holding Mechanism
A controlled buffer, pending request, inactive DMA descriptor,
disabled forwarding entry, sealed output region, or equivalent
representation retaining a Candidate Act in a Non-Effective State.
DC-2104 — Candidate Act Descriptor Component
A mechanism configured to construct or verify the effectuation-
relevant representation of the proposed operation.
PED-2105 — Protected Enforcement Domain
A protected authority component configured to validate the applicable
Candidate Act, Authority Object, runtime context, policy state, and
designated Finality Sink.
Das Expires 19 April 2027 [Page 859]
Internet-Draft Protected AI Execution Finality October 2026
AS-2106 — Protected Authority Store
An authenticated source of authorized operation classes, workload
identities, destinations, protected data scopes, hardware boundaries,
and applicable policy conditions.
PS-2107 — Protected Execution-State Store
A mechanism maintaining required nonce state, authorization epochs,
protected usage counters, revocation versions, hardware freshness,
capability consumption, and validation commitments.
EV-2108 — Protected Validation-Evidence Component
A mechanism configured to generate or commit a LAVR, AVR, Fabric
Transfer LAVR, authenticated receipt, sealed commitment, or
equivalent protected validation evidence where required.
CR-2109 — Scoped Execution-Capability Mechanism
A protected component configured to generate, register, derive,
release, or activate the execution-enabling capability corresponding
to the validated Candidate Act.
HL-2110 — Hardware Finality Latch
A hardware-controlled execution-enablement mechanism preventing the
governed operation from crossing the designated finality boundary
without required capability verification.
HC-2111 — Hardware Enforcement Controller
A NIC, SmartNIC, DPU, GPU controller, FPGA, ASIC, protected gateway
processor, accelerator interconnect controller, secure memory
controller, or equivalent hardware-associated enforcement component.
FS-2112 — Hardware Finality Sink
An effectuation interface configured to verify the capability and
mandatory protected state immediately before admitting, forwarding,
switching, copying, transmitting, storing, or otherwise effectuating
the Candidate Act.
HF-2113 — Hardware Freshness Mechanism
A trusted monotonic counter, device epoch, fabric sequence number,
secure clock, protected switch-state generation, or equivalent
protected freshness source.
Das Expires 19 April 2027 [Page 860]
Internet-Draft Protected AI Execution Finality October 2026
WM-2114 — Optional Out-of-Band Monitoring Domain
An isolated monitoring component configured to produce authenticated
monitoring-state information where the selected embodiment requires
watchdog-dependent authorization.
GV-2115 — Optional Confidential Governance Environment
A confidential VM or separately protected governance node configured
to provide authenticated authorization services and applicable
hardware-rooted attestation.
FM-2116 — Authenticated Fabric-Management Interface
A protected communication mechanism configured to distribute bounded
capability state or authorized hardware-control entries.
RV-2117 — Protected Revocation Controller
A mechanism configured to advance required authorization versions,
invalidate capability use, and prevent subsequent effectuation under
superseded mandatory state.
OS-2118 — Protected Effectuation Outcome Store
A mechanism maintaining pending, authorized, reserved, admitted,
completed, revoked, and indeterminate operation outcomes.
RC-2119 — Recovery and State-Reconciliation Component
A protected mechanism configured to reconcile authorization and
effectuation state after device reset, workload restoration,
communication failure, or interrupted transfer.
The components may be implemented within one protected hardware
device, a single server, or distributed across authenticated physical
and virtualized systems.
Not every described component is required in every claimed variant.
11.21.3. WF-21.3 — Definition of Hardware Finality Latch
A Hardware Finality Latch is a hardware-enforced implementation of a
Finality Latch that prevents a governed Candidate Act from crossing
its Execution-Finality Boundary unless the required scoped execution
capability or corresponding protected enablement condition is
verified.
Das Expires 19 April 2027 [Page 861]
Internet-Draft Protected AI Execution Finality October 2026
The latch may control:
(a) queue admission;
(b) DMA mapping;
(c) memory access;
(d) network forwarding;
(e) storage commitment;
(f) accelerator egress;
(g) RF activation;
(h) optical modulation; or
(i) another consequential interface.
The Hardware Finality Latch may be implemented within a processor,
accelerator, controller, NIC, SmartNIC, DPU, FPGA, ASIC, or
equivalent enforcement component.
The existence of a hardware device does not independently establish
that an effectuation path is non-bypassable.
The latch must actually control the specified consequential
interface.
11.21.4. WF-21.4 — Distinction Among PED, Finality Gate, Finality Sink,
and Latch
The embodiment distinguishes four functions.
Protected Enforcement Domain: Validates protected authority,
applicable policies, Candidate Act conditions, and required
authorization state.
Finality Gate: The mandatory mediation arrangement preventing the
Candidate Act from bypassing the required protected finality
sequence.
Finality Sink: The actual effectuation interface at which the
required operation-specific capability is verified before the
governed effect.
Das Expires 19 April 2027 [Page 862]
Internet-Draft Protected AI Execution Finality October 2026
Hardware Finality Latch: The hardware-controlled enabling or
admission condition preventing the operation from crossing the
boundary until required verification succeeds.
These functions may be performed by physically separate devices or
integrated within one protected controller.
For example, a DPU may contain both a protected authorization
component and a forwarding Finality Sink.
In that arrangement, functional integration does not eliminate the
requirements for protected authority validation, capability-dependent
verification, and non-bypassable hardware effectuation control.
11.21.5. WF-21.5 — Establishment of the Hardware Enforcement Boundary
Before permitting governed operations, the system identifies the
physical or virtualized interfaces capable of producing the specified
effect.
For network transmission, the boundary may comprise a protected NIC
transmit queue or DPU forwarding pipeline.
For accelerator data export, the boundary may comprise a controlled
accelerator memory interface, DMA queue, or interconnect admission
point.
For protected storage, the boundary may comprise a storage controller
or commit-admission interface.
For device actuation, the boundary may comprise a protected
controller enablement interface.
The system ensures that the AI workload cannot perform the governed
operation through another accessible path bypassing the required
verification.
The particular implementation may use:
(a) IOMMU restrictions;
(b) protected DMA mappings;
(c) device queue ownership;
(d) trusted firmware;
(e) hardware forwarding controls;
Das Expires 19 April 2027 [Page 863]
Internet-Draft Protected AI Execution Finality October 2026
(f) hypervisor-managed device access;
(g) protected memory apertures;
(h) access-control registers; or
(i) equivalent mechanisms.
Non-bypassability must be demonstrated against the actual threat
model and all relevant accessible effectuation paths.
11.21.6. WF-21.6 — Candidate Act Generation
AE-2101 performs an AI computation and prepares a consequential
operation.
The operation may comprise:
(a) a packet or network request;
(b) a DMA transfer;
(c) a tensor export;
(d) a fabric routing instruction;
(e) a credential-mediated request;
(f) an accelerator output;
(g) a protected storage operation; or
(h) an actuation command.
The operation is classified as Candidate Hardware-Effectuation Act
CA-2120.
The AI workload may generate all necessary parameters to describe the
operation.
However, generation of the operation does not itself satisfy
protected execution authorization.
11.21.7. WF-21.7 — Interception and Non-Effective State
CI-2102 intercepts or controls CA-2120 before the hardware
effectuation boundary.
Das Expires 19 April 2027 [Page 864]
Internet-Draft Protected AI Execution Finality October 2026
HQ-2103 maintains the operation in a Non-Effective State.
The held representation may comprise:
candidate_act_id;
source_workload_id;
operation_class;
source_interface;
target_interface;
payload_reference;
operation_parameters;
policy_epoch;
hardware_sink_id;
status = NON_EFFECTIVE.
In a network implementation, the packet or request may be held before
protected transmit-queue admission.
In a DMA implementation, the DMA descriptor may remain inactive.
In an accelerator implementation, the output may remain within a
protected memory region or blocked transfer queue.
In a switching implementation, the forwarding entry may remain
disabled.
The operation cannot become effective through the governed interface
merely because it has been placed into a queue.
11.21.8. WF-21.8 — Candidate Act Descriptor Formation
DC-2104 constructs a canonical Candidate Act Descriptor.
A non-limiting descriptor includes:
candidate_act_id;
source_workload_identity;
Das Expires 19 April 2027 [Page 865]
Internet-Draft Protected AI Execution Finality October 2026
operation_class;
source_domain;
destination_domain;
target_resource;
operation_parameters;
payload_digest;
data_class;
authorized_route;
hardware_queue_or_interface;
policy_epoch;
revocation_epoch;
nonce;
expiry;
hardware_freshness_reference;
finality_sink_identity.
Only attributes required by the particular Authority Object or
embodiment are mandatory.
The descriptor represents the concrete operation whose hardware
effectuation is requested.
11.21.9. WF-21.9 — Canonical Hardware Operation Representation
In one illustrative cryptographic implementation:
Dhardware = Canon_v(SRC, ACT, DST, DATA, PARAM, ROUTE, EPOCH, FRESH,
SINK)
where:
Dhardware denotes the canonical Candidate Act Descriptor;
SRC denotes the requesting workload or source domain;
Das Expires 19 April 2027 [Page 866]
Internet-Draft Protected AI Execution Finality October 2026
ACT denotes the consequential operation;
DST denotes the destination or target;
DATA denotes the relevant payload or data-class representation;
PARAM denotes effectuation-relevant parameters;
ROUTE denotes the required network, memory, or fabric route;
EPOCH denotes applicable protected policy and revocation state;
FRESH denotes required hardware-freshness conditions; and
SINK denotes the designated hardware Finality Sink.
An illustrative digest is:
hHardware = H("DAS-HARDWARE-ACT-v1" || Encode(Dhardware))
The particular encoding, hash algorithm, and domain-separation label
are implementation choices.
The hardware Finality Sink must use a representation or protected
comparison procedure consistent with the authorization semantics.
11.21.10. WF-21.10 — Acquisition of Hardware Effectuation Authority
PED-2105 obtains or resolves the applicable Authority Object.
The authority may identify:
(a) authorized workload;
(b) permitted consequential operation;
(c) protected data classification;
(d) source and destination restrictions;
(e) permitted fabric or network route;
(f) authorized hardware interface;
(g) applicable runtime conditions;
(h) policy epoch;
Das Expires 19 April 2027 [Page 867]
Internet-Draft Protected AI Execution Finality October 2026
(i) revocation conditions;
(j) usage limits;
(k) hardware-freshness requirements; and
(l) designated Finality Sink.
Where the operation is a fabric transfer, the applicable source-
domain, destination-domain, workload-graph, transfer-envelope, and
route conditions are validated.
Where the operation depends upon a hardware watchdog, the required
monitoring-state version is separately validated.
Where the capability issuer is an attested confidential governance
node, the required issuer attestation is validated.
These are different authorization conditions and need not all apply
to every hardware embodiment.
11.21.11. WF-21.11 — Protected Authorization Predicate
An illustrative authorization predicate is:
Vhardware = Pact AND Psource AND Ptarget AND Pscope AND Pstate AND
Psink
where:
Vhardware denotes the protected authorization result;
Pact verifies the Candidate Act;
Psource verifies required workload or source-domain authority;
Ptarget verifies destination or receiving-domain authority;
Pscope verifies authorized operation, data, resource, route, or
transfer scope;
Pstate verifies protected policy, revocation, usage, and freshness
conditions; and
Psink verifies the designated hardware Finality Sink.
Additional attestation, monitoring, or hardware-integrity predicates
are incorporated where required by the selected embodiment.
Das Expires 19 April 2027 [Page 868]
Internet-Draft Protected AI Execution Finality October 2026
Failure of any mandatory predicate prevents issuance or availability
of the corresponding execution capability.
11.21.12. WF-21.12 — Protected Authorization-State Transition
Upon successful validation, PED-2105 performs the protected-state
operation required by CA-2120.
Such an operation may comprise:
(a) reserving a single-use authorization;
(b) registering a nonce;
(c) verifying a protected policy epoch;
(d) checking revocation state;
(e) allocating a bounded transfer quota;
(f) recording a permitted route;
(g) binding the current hardware epoch;
(h) registering the Candidate Act Descriptor commitment; or
(i) reserving an operation-specific capability.
Where a restricted grant is subject to concurrent requests, protected
state prevents unauthorized double consumption.
An incomplete mandatory state transition does not establish
successful execution authorization.
11.21.13. WF-21.13 — Protected Validation-Evidence Commitment
EV-2108 generates or commits the required validation evidence.
An illustrative record comprises:
receipt_id;
candidate_act_id;
descriptor_digest;
authority_reference;
Das Expires 19 April 2027 [Page 869]
Internet-Draft Protected AI Execution Finality October 2026
validated_predicate_reference;
protected_state_transition;
policy_epoch;
nonce;
hardware_freshness_reference;
finality_sink_id;
authorization_result;
protected_authentication.
The evidence may comprise a LAVR, Fabric Transfer LAVR, AVR,
authenticated commitment, or another supported protected validation
record.
Where pre-effectuation evidence commitment is a required condition,
the record is committed before, or atomically with, capability
availability.
A packet log, DMA completion record, or hardware monitoring report
created after effectuation does not substitute for required protected
pre-release validation evidence.
11.21.14. WF-21.14 — Scoped Hardware Execution Capability
CR-2109 generates or makes available the capability corresponding to
the validated Candidate Act.
The capability may contain or securely reference:
capability_id;
candidate_act_descriptor_digest;
authorized_operation;
source_identity;
destination_identity;
permitted_data_class;
authorized_route;
Das Expires 19 April 2027 [Page 870]
Internet-Draft Protected AI Execution Finality October 2026
authorized_queue_or_interface;
policy_epoch;
revocation_epoch;
nonce;
expiry;
remaining_usage;
hardware_freshness_reference;
validation_evidence_digest;
finality_sink_id.
The capability may be implemented as:
(a) a signed authorization artifact;
(b) a MAC-authenticated permit;
(c) a protected hardware lookup entry;
(d) an authenticated DMA descriptor;
(e) a queue-pair capability;
(f) a protected forwarding grant;
(g) a sealed capability handle; or
(h) an equivalent bounded hardware-enablement condition.
The representation alone does not establish a non-bearer capability
unless the required context, operation, state, usage, and sink
restrictions are enforced.
11.21.15. WF-21.15 — Illustrative Capability Authentication
An illustrative cryptographic capability representation is:
Chardware = Sign_skPED(Encode(hHardware, hReceipt, Scope, Epoch,
Freshness, Nonce, Expiry, Sink))
where:
Das Expires 19 April 2027 [Page 871]
Internet-Draft Protected AI Execution Finality October 2026
Chardware denotes the scoped execution capability;
hHardware denotes the Candidate Act Descriptor digest;
hReceipt denotes the required validation-evidence commitment;
Scope denotes authorized operation scope;
Epoch denotes applicable protected policy state;
Freshness denotes required hardware freshness;
Nonce denotes a freshness or anti-replay value;
Expiry denotes the authorized validity limit; and
Sink denotes the designated hardware Finality Sink.
The selected implementation may authenticate a protected capability-
table entry instead of performing an asymmetric signature
verification for every hardware transfer.
The mandatory security property is that the actual hardware effect
remains dependent upon the valid bounded authorization.
11.21.16. WF-21.16 — Capability Delivery to the Hardware Controller
The capability may be delivered through:
(a) an authenticated device-management channel;
(b) protected inter-processor communication;
(c) a DPU management interface;
(d) a SmartNIC control plane;
(e) a protected PCIe control queue;
(f) an HSM-authenticated message;
(g) a protected local capability table; or
(h) an equivalent authenticated interface.
The hardware controller verifies the origin and integrity of
capability information.
Das Expires 19 April 2027 [Page 872]
Internet-Draft Protected AI Execution Finality October 2026
A requesting workload cannot install unrestricted forwarding or DMA
permissions merely by writing ordinary device metadata.
The controller associates the capability with the actual governed
operation.
11.21.17. WF-21.17 — Hardware Finality Sink Verification
Immediately before permitting the governed operation, FS-2112
verifies the applicable execution capability.
The verification includes required checks of:
(a) capability authenticity;
(b) actual operation correspondence;
(c) source identity;
(d) destination identity;
(e) operation scope;
(f) relevant data classification;
(g) route or queue restrictions;
(h) protected policy state;
(i) revocation state;
(j) nonce and expiry;
(k) hardware-freshness state;
(l) validation-evidence commitment;
(m) usage or consumption state; and
(n) Finality Sink identity.
The Finality Sink uses the actual hardware-visible operation
attributes or authenticated references sufficient to reconstruct the
relevant authorization context.
An earlier software allow decision does not independently establish
successful hardware Finality Sink verification.
Das Expires 19 April 2027 [Page 873]
Internet-Draft Protected AI Execution Finality October 2026
11.21.18. WF-21.18 — Hardware Effectuation Predicate
An illustrative predicate is:
PermitHardwareEffect =
Auth(C) AND
Match(C,Dactual) AND
ScopeValid(C) AND
StateValid(C) AND
FreshnessValid(C) AND
SinkValid(C)
where:
C denotes the scoped capability;
Dactual denotes the actual operation presented for hardware
effectuation;
Auth verifies capability authenticity;
Match verifies required descriptor correspondence;
ScopeValid verifies permitted source, destination, resource, and
operation scope;
StateValid verifies required policy, revocation, receipt, and usage
conditions;
FreshnessValid verifies mandatory hardware-freshness state; and
SinkValid verifies the designated hardware Finality Sink.
The controlled hardware effect is permitted only when all mandatory
predicates succeed.
11.21.19. WF-21.19 — Hardware Finality Latch State Machine
The hardware latch may implement the following states:
DISABLED;
Das Expires 19 April 2027 [Page 874]
Internet-Draft Protected AI Execution Finality October 2026
PENDING_AUTHORIZATION;
AUTHORIZED;
ARMED;
EFFECTUATION_IN_PROGRESS;
CONSUMED;
REVOKED;
FAULT;
INDETERMINATE.
An illustrative progression is:
DISABLED → PENDING_AUTHORIZATION → AUTHORIZED → ARMED →
EFFECTUATION_IN_PROGRESS → CONSUMED.
The transition into ARMED is permitted only when the required
protected capability and state verify.
A revoked or invalid capability cannot arm the latch for the affected
operation.
Where the interface supports partial transfers,
EFFECTUATION_IN_PROGRESS may be associated with bounded units or
windows.
A failed operation does not automatically restore a consumed
capability to an unused state.
11.21.20. WF-21.20 — Hardware-Latched DMA and Accelerator Transfer
For an accelerator or DMA implementation, the proposed transfer may
be represented by an inactive DMA descriptor or protected transfer
queue entry.
The PED validates:
(a) source domain;
(b) destination domain;
(c) data classification;
Das Expires 19 April 2027 [Page 875]
Internet-Draft Protected AI Execution Finality October 2026
(d) memory-region restrictions;
(e) transfer size;
(f) authorized route;
(g) workload graph;
(h) policy state; and
(i) applicable protected freshness.
The system commits required validation evidence and makes available a
Fabric Transfer Capability.
The hardware-associated Finality Sink verifies the capability before
activating the relevant descriptor, queue, memory mapping, fabric
lane, or interconnect operation.
An unauthorized transfer remains non-admitting.
The source accelerator's ability to address a memory location or
generate a DMA descriptor does not independently authorize the
corresponding cross-domain transfer.
11.21.21. WF-21.21 — SmartNIC and DPU Network Forwarding
In one implementation, HC-2111 comprises a SmartNIC or DPU
controlling network egress.
The agent or workload prepares a packet, service request, or data-
transfer operation.
The request remains pending before the governed forwarding boundary.
The applicable protected authority validates the concrete operation
and releases a scoped capability.
The SmartNIC or DPU installs or verifies the corresponding
authenticated forwarding authorization.
The Finality Sink compares the actual packet flow, destination,
protected workload identity, operation scope, and mandatory state
against the capability.
The packet or transfer is admitted only within the authorized scope.
Das Expires 19 April 2027 [Page 876]
Internet-Draft Protected AI Execution Finality October 2026
A generic host firewall allow rule does not replace the capability-
dependent protected finality sequence where that sequence is
mandatory.
11.21.22. WF-21.22 — Hardware Fast-Path Verification
In a latency-sensitive implementation, the PED performs comparatively
higher-cost authorization outside the fast transfer path.
The fast path uses a protected local authorization entry.
An illustrative entry contains:
capability_id;
source_identity;
destination_identity;
operation_class;
route_id;
queue_id;
maximum_bytes;
remaining_bytes;
policy_epoch;
hardware_epoch;
next_sequence;
expiry;
protected_validation_reference;
status.
The hardware interface performs a bounded local verification before
admitting the operation.
The fast path may use protected lookup tables, sequence counters,
short-lived authentication tags, route grants, or equivalent
authenticated admission mechanisms.
Das Expires 19 April 2027 [Page 877]
Internet-Draft Protected AI Execution Finality October 2026
Line-rate performance is an implementation objective and must be
established through actual hardware evaluation.
The architecture does not claim a measured latency or throughput
without corresponding test evidence.
11.21.23. WF-21.23 — Continuous and Windowed Transfer Authorization
Where the governed operation comprises a stream, the system may
divide it into:
(a) packets;
(b) DMA blocks;
(c) memory pages;
(d) tensor slices;
(e) transfer windows; or
(f) other bounded transfer units.
A protected capability or authenticated rolling state governs each
required unit or window.
The hardware Finality Sink verifies that the unit remains within the
permitted destination, route, size, policy, sequence, and usage
conditions.
A capability permitting one bounded transfer does not automatically
authorize subsequent unauthorized units.
The enforcement granularity is determined under the specified
enforcement profile and protected Authority Object.
11.21.24. WF-21.24 — Hardware-Freshness and Replay Protection
HF-2113 provides a protected freshness reference.
The reference may comprise:
(a) a monotonic counter;
(b) a secure boot epoch;
(c) a fabric sequence number;
Das Expires 19 April 2027 [Page 878]
Internet-Draft Protected AI Execution Finality October 2026
(d) an authenticated device generation;
(e) a trusted clock;
(f) protected switch state; or
(g) a hardware-attested nonce.
The scoped capability is associated with the required freshness
value.
The Finality Sink verifies the current protected freshness before
effectuation.
An earlier capability is rejected when its mandatory freshness
binding is incompatible with the current protected state.
A device reset or workload snapshot does not automatically restore an
earlier authorization generation.
11.21.25. WF-21.25 — Optional Confidential Governance Node
Where the embodiment of enforcement point 79 applies, GV-2115
comprises a governance compute node executing within a confidential
virtual-machine environment.
The governance node provides an authenticated attestation record
identifying the approved workload measurement and protected execution
configuration.
The PED verifies the attestation against:
(a) an approved hardware trust root;
(b) registered governance identity; and
(c) applicable protected policy state.
An operation-scoped execution capability depends upon both the
required acceptable governance-node attestation and successful
Candidate Act authorization.
The authenticated fabric-management path conveys capability
information to the hardware effectuation controller.
The hardware Finality Sink verifies the required issuing-governance
attestation state as well as the concrete operation.
Das Expires 19 April 2027 [Page 879]
Internet-Draft Protected AI Execution Finality October 2026
Successful confidential-VM attestation does not independently
authorize transmission.
11.21.26. WF-21.26 — Optional Hardware Watchdog Interlock
Where enforcement point 62–67 apply, WM-2114 provides an out-of-band
monitoring-state record.
The record identifies:
(a) workload identity;
(b) monitoring-state version;
(c) validity condition; and
(d) enforcement-state indicator.
The PED evaluates the monitoring state as a required input to the
operation-specific authorization.
The capability is bound to the applicable monitoring-state version
when required.
The hardware Finality Sink checks the required current monitoring
state before effectuation.
If the monitoring-state condition becomes invalid, stale, revoked,
inconsistent, or unavailable, the affected operation is refused.
A watchdog alert alone is not treated as hardware prevention unless
the actual Finality Sink enforces the corresponding state.
11.21.27. WF-21.27 — Protected Revocation Fence
RV-2117 maintains the required revocation or authorization-generation
state.
Revocation may arise from:
(a) policy withdrawal;
(b) capability expiry;
(c) protected monitoring-state invalidation;
(d) governance attestation failure;
Das Expires 19 April 2027 [Page 880]
Internet-Draft Protected AI Execution Finality October 2026
(e) source-workload revocation;
(f) destination authorization withdrawal;
(g) hardware integrity failure; or
(h) another protected security condition.
The revocation mechanism updates the corresponding protected state.
The Finality Sink rejects a capability when its required state is no
longer acceptable.
A revoked operation cannot be reenabled merely by retaining an
earlier software allow decision or replaying a previous hardware-
control message.
11.21.28. WF-21.28 — Protection Against Hardware Bypass Paths
The system identifies alternative effectuation paths available to the
AI workload.
Potential bypass paths include:
(a) direct access to another NIC;
(b) direct DMA through an unprotected device;
(c) use of an alternate accelerator transfer interface;
(d) manipulation of a hardware queue;
(e) unauthorized device passthrough;
(f) host-mediated copying through an unprotected path;
(g) direct connection to a different network namespace;
(h) modification of firmware-controlled forwarding rules; or
(i) another accessible interface capable of producing the same
governed effect.
The implementation restricts or equivalently mediates the paths
within its specified protection scope.
A hardware latch controlling only one path does not establish
protection against another unrestricted path.
Das Expires 19 April 2027 [Page 881]
Internet-Draft Protected AI Execution Finality October 2026
the specified non-bypassable property must be supported by actual
path coverage.
11.21.29. WF-21.29 — Independent Hardware Effectuation Verification
The hardware controller performs the required verification
independently of the requesting AI process.
The AI workload may provide a request identifier, descriptor
reference, or capability representation.
However, it cannot determine the final authorization result by
modifying an ordinary process variable or sending an untrusted allow
flag.
The Finality Sink verifies protected authorization material and
actual hardware-visible operation attributes.
Where the operation requires receiving-side finality control,
authorization at a source-side NIC does not automatically authorize a
downstream database commit, payment, or other independent receiving-
side consequence.
The actual protected effectuation boundary remains identifiable.
11.21.30. WF-21.30 — Capability Consumption and Concurrency
Where the capability is single-use, the hardware controller or
protected state service performs the required consumption operation.
A representative state record comprises:
capability_id;
candidate_act_digest;
authorized_sink_id;
remaining_uses;
remaining_transfer_bytes;
hardware_epoch;
state_version;
status.
Das Expires 19 April 2027 [Page 882]
Internet-Draft Protected AI Execution Finality October 2026
Where two execution requests compete for the same restricted grant,
the protected system prevents both from independently consuming it
outside the allowed usage conditions.
Where repeated or windowed use is authorized, the implementation
enforces its bounded usage allowance.
A protected consumption update does not necessarily establish
successful remote completion.
11.21.31. WF-21.31 — Device Reset and Recovery
Following a hardware reset, firmware restart, power interruption, or
controller failover, RC-2119 reconciles the required protected state.
The recovery procedure may verify:
(a) current device identity;
(b) secure boot or firmware state;
(c) hardware freshness;
(d) capability-table continuity;
(e) protected usage state;
(f) authorization epochs;
(g) revocation state;
(h) pending operation references; and
(i) observed or confirmed effectuation outcomes.
The controller does not automatically treat restored queue contents
or cached capability entries as valid.
Required current authorization conditions are reestablished before
further governed effectuation.
Previously consumed or revoked capabilities are not restored through
replay of earlier device state.
11.21.32. WF-21.32 — Partial Transfer and Indeterminate Completion
A hardware transfer may fail after partial admission or delivery.
Das Expires 19 April 2027 [Page 883]
Internet-Draft Protected AI Execution Finality October 2026
The system distinguishes:
Pending: No governed transfer effect has occurred.
Reserved: Authorization has been reserved, but external effectuation
has not been confirmed.
Partially effective: Some bounded transfer units have crossed the
controlled boundary.
Confirmed effective: Sufficient evidence establishes completion of
the specified effect.
Indeterminate: Available evidence does not establish whether the
relevant effect completed.
A timeout or device reset does not automatically prove that a remote
destination received no data.
Recovery uses protected transfer identifiers, sequence numbers,
completion records, or authenticated acknowledgments where available.
The system does not automatically replay uncertain consequential
operations when that could cause an unauthorized duplicate effect.
11.21.33. WF-21.33 — Illustrative NIC Egress Finality
An AI agent generates a request to transmit confidential enterprise
data to an external service.
The request is intercepted before the controlled NIC transmit
interface.
The proposed transmission is classified as a Candidate Act and held
in a Non-Effective State.
The PED validates the requested destination, data scope, authorized
purpose, workload identity, protected policy state, and required
freshness.
The protected mechanism commits the applicable validation evidence
and releases a scoped execution capability.
The NIC Finality Sink reconstructs or verifies the actual
transmission descriptor.
The NIC permits the authorized transfer only when the required
capability verifies.
Das Expires 19 April 2027 [Page 884]
Internet-Draft Protected AI Execution Finality October 2026
If the agent substitutes an unauthorized destination, the Finality
Sink rejects the changed operation.
Possession of the data and ability to generate a packet do not
independently authorize its transmission.
11.21.34. WF-21.34 — Illustrative GPU DMA Finality
An AI accelerator produces a protected tensor.
The workload prepares a DMA descriptor to copy the tensor into
another memory domain.
The corresponding hardware transfer interface retains the descriptor
in a non-admitting state.
The PED validates the source and destination domains, data class,
memory region, size, permitted route, and protected authorization
state.
The required validation evidence is committed.
A bounded Fabric Transfer Capability becomes available.
The hardware Finality Sink verifies the capability against the actual
DMA descriptor.
Only the authorized transfer is admitted.
A modified destination address or unauthorized memory region causes
required verification to fail.
The example illustrates the difference between executing a tensor
computation and possessing authority to export the resulting data.
11.21.35. WF-21.35 — Illustrative DPU Watchdog and Revocation Interlock
An AI workload has an outstanding capability permitting a bounded
network operation.
An isolated hardware-monitoring component detects a condition
requiring revocation.
The protected monitoring-state version advances.
The affected DPU forwarding Finality Sink checks the current required
monitoring or revocation version before admitting the operation.
Das Expires 19 April 2027 [Page 885]
Internet-Draft Protected AI Execution Finality October 2026
The earlier capability no longer satisfies the mandatory state
condition.
The DPU refuses the operation.
The prevention occurs through the forwarding interlock rather than
solely through an out-of-band alert.
If the corresponding operation had already crossed the controlled
boundary before the revocation became effective, the system records
the completed effect instead of claiming retroactive prevention.
11.21.36. WF-21.36 — Illustrative Confidential Governance VM and
SmartNIC
A protected governance VM authenticates its hardware-rooted
measurement.
The PED verifies the registered governance identity and approved
attestation state.
An AI compute node proposes an external data transfer.
The PED validates the concrete Candidate Act.
The protected system performs required state and evidence operations
and makes available an operation-scoped capability.
An authenticated fabric-management channel conveys the capability or
protected capability entry toward the SmartNIC.
The SmartNIC verifies the issuer identity, required attestation
state, Candidate Act binding, policy state, freshness, and Finality
Sink identity.
The transfer proceeds only when the hardware Finality Sink authorizes
the actual operation.
If the governance-node attestation becomes invalid under the
mandatory policy, further affected authorization is withheld or
refused as required by the protected state rules.
11.21.37. WF-21.37 — Failure and Fail-Closed Conditions
The hardware Finality Sink refuses the governed effect when any
mandatory condition is absent, invalid, revoked, expired, replayed,
inconsistent, or unverifiable.
Das Expires 19 April 2027 [Page 886]
Internet-Draft Protected AI Execution Finality October 2026
Non-limiting conditions include:
(a) missing execution capability;
(b) invalid capability authentication;
(c) unauthorized Candidate Act;
(d) source identity mismatch;
(e) destination mismatch;
(f) prohibited data classification;
(g) unauthorized memory region;
(h) transfer-size violation;
(i) fabric-route inconsistency;
(j) unauthorized hardware queue;
(k) stale policy epoch;
(l) revoked authorization;
(m) expired nonce;
(n) consumed or replayed capability;
(o) invalid hardware freshness;
(p) failed required protected-state transition;
(q) failed required validation-evidence commitment;
(r) invalid required governance attestation;
(s) invalid monitoring-state version;
(t) missing required monitoring state;
(u) Finality Sink mismatch;
(v) unavailable mandatory hardware verifier; or
(w) failure to establish mandatory non-bypassable path coverage.
Das Expires 19 April 2027 [Page 887]
Internet-Draft Protected AI Execution Finality October 2026
A hardware or software fault does not create unrestricted fallback
execution authority.
11.21.38. WF-21.38 — PHOSITA Verification and Negative Tests
A person having ordinary skill in hardware security, NIC/SmartNIC/DPU
design, accelerator architecture, DMA systems, protected computing,
cryptography, and network enforcement may verify the described system
through controlled testing.
Test 1 — Authorized hardware operation: Submit a Candidate Act with
valid protected authorization. The hardware Finality Sink permits
only the authorized effect.
Test 2 — Missing capability: Present the operation without the
required capability. The hardware latch remains non-admitting.
Test 3 — Forged capability: Modify the capability authentication.
Hardware verification fails.
Test 4 — Wrong destination: Substitute another destination after
authorization. The Finality Sink refuses the changed operation.
Test 5 — Wrong hardware interface: Present the capability at a
different Finality Sink. Required sink binding fails.
Test 6 — DMA bypass: Attempt data movement through an unauthorized
DMA descriptor or mapping. The governed transfer remains blocked.
Test 7 — NIC bypass: Attempt transmission through another accessible
network interface. The operation is blocked or subjected to
equivalent mandatory verification.
Test 8 — Hardware latch: Verify that the interface remains disabled
or non-admitting until the required protected capability succeeds.
Test 9 — Transfer-size limit: Exceed the permitted transfer
allowance. The unauthorized excess is denied.
Test 10 — Streaming transfer: Verify authorized bounded transfer
units and refusal of subsequent units after mandatory authorization
becomes invalid.
Test 11 — Route drift: Change a required fabric route during transfer
progression. Further unauthorized units are withheld.
Test 12 — Hardware replay: Reuse a capability bound to an
incompatible previous hardware epoch. Verification fails.
Das Expires 19 April 2027 [Page 888]
Internet-Draft Protected AI Execution Finality October 2026
Test 13 — Protected counter rollback: Attempt to restore prior
counter or sequence state. The protection mechanism rejects
unauthorized replay under its specified threat model.
Test 14 — Policy revocation: Revoke an applicable authorization
before effectuation. The Finality Sink refuses the affected
operation.
Test 15 — Monitoring-state invalidation: Advance the protected
watchdog state and verify rejection of affected superseded
capabilities.
Test 16 — Governance attestation mismatch: Present an invalid
required issuer attestation. Dependent authorization fails.
Test 17 — Confidential governance key isolation: Attempt unrestricted
extraction of protected issuance keys from an AI compute process.
The protected key boundary refuses access.
Test 18 — Evidence-commitment failure: Interrupt mandatory protected
evidence commitment. No valid corresponding capability becomes
available.
Test 19 — Concurrent capability use: Submit competing operations
against one restricted grant. Protected consumption prevents
unauthorized double use.
Test 20 — Fast-path enforcement: Perform cold-path authorization and
verify mandatory local hardware capability checks before each
governed transfer unit or window.
Test 21 — Hardware verifier outage: Disable a mandatory hardware-
verification component. The corresponding governed effect remains
blocked.
Test 22 — Device reset: Restore device state after reset and verify
current hardware freshness, policy, and capability state.
Test 23 — Partial effectuation: Interrupt a transfer after some units
cross the boundary. The system preserves the distinction between
delivered and pending units.
Test 24 — Indeterminate remote completion: Simulate an uncertain
downstream result and verify that recovery does not automatically
claim prevention or success.
Das Expires 19 April 2027 [Page 889]
Internet-Draft Protected AI Execution Finality October 2026
Test 25 — Single-node architecture: Implement PED and Finality Sink
functions in one protected device and verify their mandatory
authorization dependencies.
Test 26 — Distributed architecture: Place the PED and hardware
Finality Sink on separate nodes and verify authenticated capability
delivery and independent enforcement.
Test 27 — Source versus receiving-side authority: Permit a source
network transmission while withholding a separately required
receiving-side commit. Confirm that source authorization does not
bypass the receiving Finality Sink.
Test 28 — Hardware-only monitoring: Configure a monitor that observes
operations but does not block the actual effectuation path. Confirm
that this arrangement alone does not provide the specified preventive
finality guarantee.
The tests may use controlled GPU and DMA workloads, programmable
NIC/SmartNIC/DPU interfaces, accelerator simulators, hardware
capability tables, authenticated authorization services, protected
counters, device resets, and fault injection.
Actual latency, throughput, revocation timing, and hardware-bypass
resistance must be demonstrated through implementation-specific
testing.
11.21.39. WF-21.39 — Claim-Specific Technical Coverage
enforcement point 14 — Hardware-Rooted Enforcement
WF-21.3 through WF-21.5 and WF-21.17 through WF-21.19 describe the
hardware-protected enforcement component and the execution-enabling
latch, host execution gate, credential-release gate, or network-
forwarding gate remaining disabled without successful capability
verification.
enforcement point 48–49 — Protected Cross-Domain Fabric Transfer and
Descriptor Granularity
WF-21.6 through WF-21.16 describe proposed accelerator, memory, or
network-fabric transfers, Candidate Fabric Transfer Act descriptors,
protected authority validation, and scoped Fabric Transfer
Capabilities.
enforcement point 50 — Hardware-Latched Transfer Admission
Das Expires 19 April 2027 [Page 890]
Internet-Draft Protected AI Execution Finality October 2026
WF-21.19 through WF-21.20 describe hardware-disabled transfer
interfaces that become admitting only after required capability
verification.
enforcement point 51 — Continuous Tensor or Memory-Transfer
Validation
WF-21.23 describes bounded transfer units and authorization-state
enforcement during streaming.
enforcement point 52 — Hardware-Freshness Binding
WF-21.24 describes protected hardware generations, counters,
sequences, and replay resistance.
enforcement point 53 — Cold-Path Validation and Line-Rate Finality
WF-21.22 describes separation of higher-cost authority validation
from bounded local hardware capability verification.
enforcement point 62–63 — Hardware-Watchdog Interlock and Attested
Monitoring
WF-21.26 describes the optional isolated monitoring domain, protected
monitoring-state records, and required current-state verification.
enforcement point 64–66 — Revocation Fence, Independent Downstream
Prevention, and Monitoring Failure
WF-21.26 through WF-21.27 describe monitoring-state invalidation,
protected revocation, and fail-closed handling of mandatory
monitoring conditions. The full monitoring-state protocol remains
specified in WF-16.
enforcement point 67 — Quarantine and Effectuation-State Preservation
WF-21.31 through WF-21.32 describe preservation of protected
effectuation outcomes during failure and recovery. The complete
quarantine-state procedure remains specified in WF-16.
enforcement point 79–81 — Confidential Governance VM, Hardware
Attestation, and Key Isolation
WF-21.25 and WF-21.36 describe an optional attested confidential
governance environment and authenticated capability delivery to a
hardware Finality Sink. The complete governance attestation and
protected key-custody procedure remains specified in WF-18.
Das Expires 19 April 2027 [Page 891]
Internet-Draft Protected AI Execution Finality October 2026
enforcement point 82 — Attestation Change Disables Capability
Issuance
WF-21.25 and WF-21.27 describe refusal of dependent authorization
when mandatory governance-state conditions become invalid.
enforcement point 83 — Hardware Freshness
WF-21.24 describes capability binding to required protected counters,
boot epochs, device sequences, or equivalent hardware-freshness
state.
11.21.40. WF-21.40 — Technical Effect
The disclosed workflow establishes a protected causal relationship
between:
(a) AI computation generating a consequential operation;
(b) interception before the relevant hardware effectuation boundary;
(c) holding the Candidate Act in a Non-Effective State;
(d) construction of a concrete operation descriptor;
(e) protected validation of the applicable Authority Object and
mandatory predicates;
(f) required protected-state handling;
(g) protected validation-evidence commitment;
(h) release or availability of an operation-scoped capability;
(i) independent hardware Finality Sink verification;
(j) hardware-latch enablement for the authorized bounded operation;
(k) capability usage and freshness enforcement;
(l) revocation-dependent refusal of further affected operations; and
(m) accurate preservation of effectuation outcomes during failure and
recovery.
Das Expires 19 April 2027 [Page 892]
Internet-Draft Protected AI Execution Finality October 2026
The hardware implementation prevents an AI workload from treating
computation, packet generation, possession of accelerator memory, or
the ability to create a DMA descriptor as sufficient authority to
perform a governed transfer.
A software approval may contribute to authorization, but the final
hardware boundary must enforce the required protected capability
conditions.
A hardware watchdog may supply governance information, but
observation is not itself prevention.
A confidential governance VM may protect capability-issuance
authority, but attestation is not automatically permission for a
concrete operation.
A SmartNIC or DPU may act as a hardware Finality Sink when it
actually controls the governed effectuation path and verifies the
required scoped execution capability.
Computation is not authority to act.
Hardware connectivity is not execution authority.
A software allow decision is not a substitute for mandatory hardware
finality verification.
Monitoring a transfer is not equivalent to preventing an unauthorized
transfer.
A Hardware Finality Latch must control the actual consequential
boundary.
11.22. WF-22 — Portable Cloud-VM Agent Authority, Cross-Cloud Workload
Identity, Runtime Policy-Epoch Synchronization, Hardware-
Supervised Egress, Migration and Snapshot Protection, and
Downstream Effectuation Finality
11.22.1. WF-22.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture for enforcing operation-specific execution
authority across multiple cloud, virtualized, containerized,
confidential-computing, on-premises, hybrid-cloud, and accelerator-
backed artificial-intelligence execution environments.
Das Expires 19 April 2027 [Page 893]
Internet-Draft Protected AI Execution Finality October 2026
The architecture permits an artificial-intelligence agent to be
deployed, instantiated, replicated, restarted, rescheduled, migrated,
recovered, or relocated between supported execution substrates
without treating portability of its software, credentials,
computation state, or prior authorization context as unrestricted
authority to perform consequential operations.
The system establishes protected relationships among:
(a) an agent-execution control plane;
(b) an authenticated workload identity;
(c) a machine-verifiable execution-context measurement;
(d) a Protected Enforcement Domain maintaining applicable execution-
policy predicates and protected authorization-state versions;
(e) an operation-interception component retaining proposed
consequential operations in a Non-Effective State;
(f) an operation-specific authorization procedure;
(g) a scoped cryptographic execution capability;
(h) a designated Finality Sink; and
(i) a protected runtime-transition and recovery procedure.
The Protected Enforcement Domain validates each governed Candidate
Act against the actual operation descriptor, authenticated workload
identity, execution-context measurement, current protected policy
state, and designated effectuation boundary.
Only after the required protected authorization conditions succeed is
the corresponding scoped execution capability generated, released, or
made available.
The designated Finality Sink independently verifies the capability
before permitting the operation to become externally effective.
A workload's migration to another cloud region, replacement by a new
container, restoration from a snapshot, or restart on another compute
node does not independently revive previously consumed, revoked,
expired, or incompatible execution authority.
Das Expires 19 April 2027 [Page 894]
Internet-Draft Protected AI Execution Finality October 2026
The system additionally distinguishes admission to an artificial-
intelligence model from authorization to perform consequential
operations produced by that model.
The central technical requirement is that portability of computation
does not imply portability of unrestricted execution authority.
11.22.2. WF-22.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
CP-2201 — Agent-Execution Control Plane
A cloud, container, hypervisor, orchestration, or workload-management
component configured to deploy, manage, replicate, restart,
reschedule, or migrate an AI agent across supported execution
substrates.
AE-2202 — Artificial-Intelligence Execution Instance
An AI agent, model runtime, autonomous workload, orchestrator, tool-
execution process, or other computational instance executing on the
selected substrate.
ES-2203 — Execution Substrate
A container runtime, virtual machine, confidential virtual machine,
Kubernetes workload, on-premises compute host, hybrid-cloud
environment, accelerator-backed runtime, or equivalent supported
compute environment.
WI-2204 — Workload Identity and Measurement Component
A component configured to establish the authenticated workload
identity and machine-verifiable execution-context measurement
corresponding to the deployed instance.
AR-2205 — Workload Attestation and Measurement Record
A protected or authenticated record identifying the relevant workload
and execution-context measurements.
IM-2206 — Operation Interception Component
An enforcement-controlled component configured to intercept a
proposed consequential operation before its governed effectuation
boundary.
Das Expires 19 April 2027 [Page 895]
Internet-Draft Protected AI Execution Finality October 2026
HQ-2207 — Non-Effective Candidate Act Holding Mechanism
A controlled pending-request queue, staging buffer, inactive command
representation, blocked egress request, or equivalent mechanism
retaining the proposed operation before authorization.
DC-2208 — Candidate Act Descriptor Component
A component configured to construct or verify the canonical
representation of the proposed consequential operation.
PED-2209 — Protected Enforcement Domain
A protected authority component configured to maintain applicable
execution-policy predicates, authorization-state versions, workload-
authority conditions, and operation-specific authorization decisions.
AS-2210 — Protected Authority and Workload Policy Store
An authenticated source of Authority Objects, approved workload
measurements, permitted operations, policy versions, revocation
conditions, and effectuation-boundary restrictions.
PS-2211 — Protected Authorization-State Store
A protected mechanism maintaining policy epochs, authorization-state
versions, nonces, revocation state, capability-consumption records,
and required validation commitments.
EV-2212 — Protected Validation-Evidence Component
A mechanism configured to generate or commit protected evidence of
operation-specific validation where required by the applicable
execution-finality embodiment.
CR-2213 — Scoped Execution-Capability Component
A protected mechanism configured to issue, register, derive, release,
or activate an execution capability bound to the Candidate Act,
authenticated workload identity, authorization-state version, and
designated Finality Sink.
FS-2214 — Host or Virtual-Machine Finality Sink
A controlled host execution interface or virtual-machine boundary
that verifies the required capability before the governed operation.
FS-2215 — Cloud Network or Service-Mesh Finality Sink
Das Expires 19 April 2027 [Page 896]
Internet-Draft Protected AI Execution Finality October 2026
A gateway, service-mesh component, protected connector, or equivalent
controlled cloud service interface.
FS-2216 — Hardware-Assisted Finality Sink
A SmartNIC, DPU, protected network gateway, hardware-assisted cloud
egress controller, or accelerator-egress controller enforcing
operation-specific capability verification.
PV-2217 — Protected Policy-Version Controller
A mechanism configured to advance and validate authorization-state
versions applicable to one or more workload identities, replicas, or
execution nodes.
MG-2218 — Migration and Runtime-Transition Controller
A component configured to identify and coordinate migration,
container replacement, workload rescheduling, snapshot restoration,
and cloud-region failover.
RS-2219 — Rollback-Resistant Capability-State Component
A protected mechanism maintaining authoritative capability-
consumption, revocation, and freshness state independently of
rollback-accessible workload state.
MC-2220 — Model-Access Control Component
A component configured to govern access to a local or remote
artificial-intelligence model.
OS-2221 — Protected Effectuation-Outcome Store
A component maintaining operation states including pending, reserved,
confirmed-effective, denied, revoked, and indeterminate.
RC-2222 — Recovery and State-Reconciliation Component
A mechanism configured to reconcile workload identity, policy state,
pending Candidate Acts, capability usage, and effectuation outcomes
following runtime transitions or failures.
The identified roles may be physically integrated or distributed
across authenticated systems.
Das Expires 19 April 2027 [Page 897]
Internet-Draft Protected AI Execution Finality October 2026
The Protected Enforcement Domain, Finality Gate, and Finality Sink
retain their distinguishable functions even when implemented within
one trusted node.
11.22.3. WF-22.3 — Supported Portable AI Execution Substrates
CP-2201 supports one or more execution substrates comprising:
(a) a container runtime;
(b) a conventional virtual machine;
(c) a confidential virtual machine;
(d) a Kubernetes workload;
(e) an on-premises compute host;
(f) a hybrid-cloud computing environment;
(g) an accelerator-backed agent runtime; or
(h) another supported virtualized or distributed execution
environment.
An AI agent may execute on one substrate and subsequently be
instantiated on another.
The agent may retain its permitted computational functionality, task
context, model access, and compatible data representations.
However, the execution substrate's identity, runtime measurement,
policy state, and effectuation-boundary location may differ.
The system therefore distinguishes portable application state from
protected authorization state.
A workload's successful deployment does not automatically validate
every consequential operation proposed by the deployed instance.
11.22.4. WF-22.4 — Separation of Workload Deployment and Execution
Authority
The agent-execution control plane may authorize scheduling or
starting an AI workload.
Such orchestration authorization is distinct from protected Candidate
Act authorization.
Das Expires 19 April 2027 [Page 898]
Internet-Draft Protected AI Execution Finality October 2026
A deployment controller may determine that an agent is eligible to
run on a particular virtual machine or Kubernetes node.
That decision does not independently establish that the agent may:
(a) transmit data to any destination;
(b) apply protected credentials;
(c) write to a protected database;
(d) invoke privileged APIs;
(e) deploy software;
(f) export accelerator state;
(g) perform financial operations; or
(h) issue another governed consequential instruction.
Each operation remains subject to its applicable protected execution-
finality boundary.
11.22.5. WF-22.5 — Establishment of the Workload Identity
WI-2204 establishes an authenticated identity for the deployed AI-
agent instance.
The identity may comprise:
(a) workload service identity;
(b) agent runtime identity;
(c) container identity;
(d) virtual-machine identity;
(e) confidential-VM identity;
(f) service-account identity;
(g) protected process identity;
(h) accelerator-workload identity; or
(i) another machine-verifiable execution identity.
Das Expires 19 April 2027 [Page 899]
Internet-Draft Protected AI Execution Finality October 2026
The selected identity must identify the workload at the granularity
required by the applicable protected authority.
A service name or container label supplied by the requesting process
is not independently an authenticated identity.
Where identity is mandatory for capability verification, the Finality
Sink verifies the actual authenticated workload rather than accepting
an untrusted caller assertion.
11.22.6. WF-22.6 — Execution-Context Measurement
in the implementation described by enforcement point 91, WI-2204
validates one or more of:
(a) workload image digest;
(b) virtual-machine launch measurement;
(c) container image identifier;
(d) agent runtime identity;
(e) approved tool-policy digest;
(f) model configuration digest; or
(g) protected execution-policy state.
An illustrative measurement record comprises:
workload_id;
workload_instance_id;
execution_substrate_type;
runtime_image_digest;
vm_launch_measurement;
container_image_reference;
agent_runtime_identity;
tool_policy_digest;
model_configuration_digest;
Das Expires 19 April 2027 [Page 900]
Internet-Draft Protected AI Execution Finality October 2026
protected_execution_policy_reference;
deployment_epoch;
measurement_generation;
protected_authentication.
Only the measurements required by the selected authority are
mandatory.
A container image digest alone does not necessarily establish the
current runtime tool configuration or protected policy state.
Likewise, VM launch attestation does not automatically measure every
subsequently loaded adapter, plugin, tool, or workflow configuration.
11.22.7. WF-22.7 — Authentication of the Execution-Context Measurement
The protected system verifies the required measurement's origin and
applicability.
Such verification may comprise:
(a) authenticating workload identity;
(b) validating an attestation signature;
(c) checking an approved image digest;
(d) verifying a registered runtime identity;
(e) checking the permitted tool-policy digest;
(f) checking an approved model configuration;
(g) verifying protected policy state;
(h) confirming the deployment generation; and
(i) evaluating required freshness.
An illustrative predicate is:
Vworkload = IdentityValid AND MeasurementValid AND ContextValid AND
StateValid
Das Expires 19 April 2027 [Page 901]
Internet-Draft Protected AI Execution Finality October 2026
where the terms represent the mandatory identity, measurement,
execution-context, and protected-state conditions.
A capability issued for another workload or an incompatible measured
context does not authorize the present operation.
11.22.8. WF-22.8 — Protected Workload Authority Registration
PED-2209 associates the authenticated workload identity with
applicable Authority Objects and protected policy state.
A representative authority record comprises:
authority_id;
workload_identity;
approved_measurement_reference;
permitted_operation_classes;
authorized_destinations;
authorized_effectuation_sinks;
protected_policy_epoch;
authorization_state_version;
revocation_state;
usage_conditions;
validity_interval.
The authority may apply to:
(a) one workload instance;
(b) a defined group of replicas;
(c) a service identity;
(d) a tenant workload class;
(e) a specific execution environment; or
(f) another expressly authorized scope.
Das Expires 19 April 2027 [Page 902]
Internet-Draft Protected AI Execution Finality October 2026
The protected system distinguishes group-level authority from
authority for an individual concrete Candidate Act.
An approved workload class does not automatically authorize arbitrary
operations requested by every instance of that class.
11.22.9. WF-22.9 — Candidate Act Generation
AE-2202 performs computation and prepares a proposed consequential
operation.
Non-limiting operations include:
(a) a network request;
(b) an external API invocation;
(c) a protected connector operation;
(d) a credential-mediated action;
(e) a database modification;
(f) a storage commit;
(g) software deployment;
(h) accelerator data export; or
(i) another externally effective operation.
The operation is classified as Candidate Portable-Workload Act CA-
2223.
Computation and operation preparation do not independently confer
execution authority.
11.22.10. WF-22.10 — Interception and Non-Effective Staging
IM-2206 intercepts CA-2223 before the governed effectuation boundary.
HQ-2207 retains the operation in a Non-Effective State.
A representative pending-operation record comprises:
candidate_act_id;
workload_identity;
Das Expires 19 April 2027 [Page 903]
Internet-Draft Protected AI Execution Finality October 2026
workload_instance_id;
execution_substrate;
measurement_reference;
operation_class;
target_resource;
requested_effectuation_boundary;
authorization_state_version;
deployment_epoch;
status = NON_EFFECTIVE.
The staging component preserves the required effectuation-relevant
operation representation or authenticated reference.
A workload restart does not automatically transform a pending
Candidate Act into an authorized operation.
Likewise, migration of the staged request to another execution node
does not bypass the required protected authorization.
11.22.11. WF-22.11 — Candidate Act Descriptor
DC-2208 constructs a machine-readable Candidate Act Descriptor.
The descriptor may comprise:
candidate_act_id;
authenticated_workload_identity;
workload_instance_identity;
execution_context_measurement;
operation_class;
destination_or_recipient;
resource_identifier;
operation_parameters;
Das Expires 19 April 2027 [Page 904]
Internet-Draft Protected AI Execution Finality October 2026
payload_digest;
authorized_purpose;
policy_epoch;
authorization_state_version;
deployment_epoch;
revocation_epoch;
nonce;
expiry;
finality_sink_id.
The applicable Authority Object determines which attributes are
mandatory.
The descriptor represents the concrete consequential operation.
It is distinct from the portable workload image, orchestration
configuration, and general workload identity.
11.22.12. WF-22.12 — Canonical Candidate Act Representation
In one illustrative cryptographic implementation:
Dportable = Canon_v(W, M, ACT, TARGET, PARAM, AUTH_VERSION,
DEPLOY_EPOCH, SINK)
where:
Dportable denotes the canonical Candidate Act Descriptor;
Canon_v denotes deterministic encoding under version v;
W denotes the authenticated workload identity;
M denotes the required execution-context measurement;
ACT denotes the requested consequential operation;
TARGET denotes the recipient, destination, or resource;
PARAM denotes effectuation-relevant parameters;
Das Expires 19 April 2027 [Page 905]
Internet-Draft Protected AI Execution Finality October 2026
AUTH_VERSION denotes the protected authorization-state version;
DEPLOY_EPOCH denotes the applicable workload deployment generation;
and
SINK denotes the designated Finality Sink.
An illustrative digest is:
hPortable = H("DAS-PORTABLE-WORKLOAD-ACT-v1" || Encode(Dportable))
The specific cryptographic and encoding formats are non-limiting
implementation choices.
The protected authorizer and Finality Sink apply compatible field
interpretation.
11.22.13. WF-22.13 — Protected Operation Authorization
PED-2209 obtains the applicable Authority Object and verifies the
Candidate Act.
The validation includes applicable checks of:
(a) authenticated workload identity;
(b) execution-context measurement;
(c) authorized operation class;
(d) destination or resource scope;
(e) current execution-policy predicates;
(f) protected authorization-state version;
(g) deployment generation;
(h) revocation state;
(i) nonce and freshness;
(j) protected usage conditions; and
(k) designated effectuation boundary.
A valid workload identity does not independently authorize an
arbitrary operation.
Das Expires 19 April 2027 [Page 906]
Internet-Draft Protected AI Execution Finality October 2026
Likewise, an earlier authorization associated with a different
workload measurement or authorization-state version does not
automatically remain valid after migration or policy changes.
11.22.14. WF-22.14 — Protected Authorization Predicate
An illustrative predicate is:
Vportable = Pidentity AND Pmeasurement AND Pact AND Pscope AND
Pversion AND Pstate AND Psink
where:
Vportable denotes the protected operation-authorization result;
Pidentity verifies workload identity;
Pmeasurement verifies required execution-context state;
Pact verifies the proposed consequential operation;
Pscope verifies permitted destination, purpose, and execution scope;
Pversion verifies the current required protected authorization-state
version;
Pstate verifies revocation, nonce, usage, and freshness conditions;
and
Psink verifies the designated Finality Sink.
Additional predicates may apply according to the selected embodiment.
Failure of any mandatory predicate prevents availability of the
corresponding execution capability.
11.22.15. WF-22.15 — Protected Authorization-State Handling
Following successful validation, PED-2209 performs the required
protected authorization-state operations.
These may include:
(a) reserving an operation-specific authorization grant;
(b) checking the current policy epoch;
(c) recording the applicable authorization-state version;
Das Expires 19 April 2027 [Page 907]
Internet-Draft Protected AI Execution Finality October 2026
(d) registering or consuming a nonce;
(e) reserving a capability identifier;
(f) recording the workload measurement;
(g) recording the deployment epoch;
(h) updating a bounded usage allowance; or
(i) another required protected authorization transition.
Where a restricted grant is single-use, protected state prevents
unauthorized concurrent consumption.
Where the relevant protected state cannot be established
consistently, the operation remains non-effective.
11.22.16. WF-22.16 — Protected Validation-Evidence Commitment
Where the selected execution-finality embodiment requires a protected
validation receipt, EV-2212 commits the corresponding evidence.
An illustrative record comprises:
receipt_id;
candidate_act_id;
candidate_act_descriptor_digest;
authenticated_workload_reference;
execution_measurement_reference;
authority_object_reference;
authorization_state_version;
deployment_epoch;
protected_state_transition;
policy_epoch;
nonce;
finality_sink_id;
Das Expires 19 April 2027 [Page 908]
Internet-Draft Protected AI Execution Finality October 2026
decision;
protected_authentication.
The evidence may comprise a LAVR, AVR, authenticated validation
record, sealed commitment, or another supported protected artifact.
Where pre-capability evidence commitment is mandatory, the commitment
occurs before, or atomically with, availability of the corresponding
capability.
enforcement point 90 itself requires scoped cryptographic capability
issuance and independent Finality Sink verification. The additional
protected-receipt sequence applies where separately required by the
selected DAS finality embodiment.
11.22.17. WF-22.17 — Scoped Portable-Workload Execution Capability
CR-2213 generates or releases the scoped capability corresponding to
CA-2223.
In enforcement point 90, the capability is bound to:
(a) the Candidate Act;
(b) authenticated workload identity;
(c) authorization-state version; and
(d) designated Finality Sink.
The capability may additionally bind:
execution_context_measurement;
workload_instance_id;
authorized_operation;
destination_scope;
deployment_epoch;
policy_epoch;
revocation_epoch;
nonce;
Das Expires 19 April 2027 [Page 909]
Internet-Draft Protected AI Execution Finality October 2026
expiry;
usage_limit;
validation_evidence_reference.
The capability may comprise a cryptographically signed authorization
artifact, authenticated protected handle, MAC-authenticated permit,
sealed capability reference, or equivalent protected execution-
enablement representation.
The capability does not authorize arbitrary operations outside its
validated scope.
11.22.18. WF-22.18 — Illustrative Cryptographic Capability
In a signature-based implementation:
Cportable = Sign_skPED(Encode(hPortable, WorkloadID, MeasurementRef,
AuthVersion, DeployEpoch, Scope, Nonce, Expiry, Sink))
where:
Cportable denotes the scoped execution capability;
Sign_skPED denotes signing under PED-controlled key material;
hPortable denotes the Candidate Act Descriptor digest;
WorkloadID denotes authenticated workload identity;
MeasurementRef denotes the required execution-context measurement;
AuthVersion denotes the protected authorization-state version;
DeployEpoch denotes the applicable deployment epoch;
Scope denotes the authorized operation scope;
Nonce denotes freshness;
Expiry denotes capability validity; and
Sink denotes the designated Finality Sink.
A selected implementation may use a protected capability table or
hardware-associated authorization entry instead of transferring a
signed artifact.
Das Expires 19 April 2027 [Page 910]
Internet-Draft Protected AI Execution Finality October 2026
The required non-bearer characteristics depend upon actual workload,
operation, state, and sink verification.
11.22.19. WF-22.19 — Independent Finality Sink Verification
Before the proposed operation becomes externally effective, the
designated Finality Sink obtains or reconstructs the actual
operation.
The Finality Sink verifies:
(a) capability authenticity;
(b) Candidate Act correspondence;
(c) authenticated workload identity;
(d) required execution-context measurement;
(e) authorized operation scope;
(f) current required authorization-state version;
(g) policy epoch;
(h) revocation state;
(i) nonce and expiry;
(j) deployment epoch where mandatory;
(k) capability usage or consumption state;
(l) validation-evidence commitment where required; and
(m) designated Finality Sink identity.
The operation is refused when a mandatory verification condition
fails.
An ordinary cloud identity, authenticated network session, or
successful virtual-machine connection does not replace the required
operation-specific capability check.
11.22.20. WF-22.20 — Finality Verification Predicate
An illustrative effectuation predicate is:
Das Expires 19 April 2027 [Page 911]
Internet-Draft Protected AI Execution Finality October 2026
PermitPortableEffect =
Auth(C) AND
Match(C,Dactual) AND
WorkloadValid(C,Wactual) AND
VersionValid(C,Vcurrent) AND
StateValid(C,S) AND
SinkValid(C,F)
where:
C denotes the scoped capability;
Dactual denotes the actual operation descriptor;
Wactual denotes the authenticated executing workload;
Vcurrent denotes the protected authorization-state version currently
required;
S denotes required policy, revocation, freshness, and consumption
state; and
F denotes the designated Finality Sink.
The Finality Sink permits the effect only if the applicable
predicates succeed.
Where a workload measurement or deployment epoch is a mandatory
binding, its corresponding verification is included in WorkloadValid
or StateValid.
11.22.21. WF-22.21 — Protected Runtime Policy Updates Across Replicas
in the implementation described by enforcement point 92, CP-2201
manages multiple replicas, restarted workloads, VM instances, or
agent-execution nodes.
PV-2217 maintains the protected authorization-state version
applicable to a defined workload scope.
An illustrative protected policy record comprises:
Das Expires 19 April 2027 [Page 912]
Internet-Draft Protected AI Execution Finality October 2026
workload_scope_id;
current_authorization_version;
policy_digest;
revocation_reference;
effective_generation;
affected_workload_identities;
affected_finality_sinks;
protected_authentication.
The defined scope may encompass one workload, a replica group, or
another authorized collection of execution instances.
When a protected policy-state transition occurs, the corresponding
authorization-state version advances.
The system distinguishes a new configuration's successful deployment
from its protected effectuation-authority state.
11.22.22. WF-22.22 — Authorization-State Version Advancement
An illustrative state transition is:
AUTH_VERSION = v → v+1
where the protected new version applies to the defined workload
scope.
Possible triggers include:
(a) revocation of a destination;
(b) modification of permitted tool classes;
(c) restriction of service credentials;
(d) change of execution scope;
(e) policy update;
(f) withdrawal of a workload identity;
Das Expires 19 April 2027 [Page 913]
Internet-Draft Protected AI Execution Finality October 2026
(g) security-state transition; or
(h) another protected authorization change.
A capability bound to an incompatible prior authorization-state
version is rejected by each affected Finality Sink before admitting a
subsequent consequential operation.
The protected policy-version mechanism must be authenticated and
resistant to unauthorized rollback under its declared trust model.
11.22.23. WF-22.23 — Replica Consistency and Stale Capability Rejection
In a replicated system, different instances may have received earlier
configuration or policy information.
An agent replica may therefore retain:
(a) an earlier policy snapshot;
(b) a previously issued capability;
(c) a cached authorization result;
(d) an earlier workload measurement; or
(e) a previous deployment epoch.
The corresponding Finality Sink verifies the currently required
protected authorization-state version.
Where exact version matching is mandatory, a capability associated
with an incompatible prior version is refused.
Where a bounded validity policy is expressly permitted, the Finality
Sink applies that authenticated acceptance rule.
The system must not claim instantaneous revocation across all
replicas unless the actual protected state-distribution and
verification mechanism provides that guarantee.
An affected Finality Sink that cannot establish required current
state remains non-admitting rather than silently treating stale
authority as valid.
Das Expires 19 April 2027 [Page 914]
Internet-Draft Protected AI Execution Finality October 2026
11.22.24. WF-22.24 — Hardware-Supervised Cloud Egress
in the implementation described by enforcement point 93, the
designated Finality Sink is implemented within or through:
(a) a DPU;
(b) a SmartNIC;
(c) a protected network gateway; or
(d) a hardware-assisted cloud egress controller.
The hardware-associated Finality Sink verifies the scoped execution
capability and authenticated workload context before permitting the
governed external network effect.
The actual operation may identify:
source_workload_identity;
source_vm_or_container;
destination_service;
network_endpoint;
protocol;
operation_class;
payload_or_request_reference;
authorization_state_version;
capability_identifier.
The controller verifies the relevant fields against the authenticated
capability.
Successful cloud-network authentication, TLS establishment, virtual-
machine connectivity, or container membership does not independently
establish the required operation-specific execution authority.
11.22.25. WF-22.25 — Hardware Egress Admission Sequence
A non-limiting hardware-supervised egress sequence comprises:
Das Expires 19 April 2027 [Page 915]
Internet-Draft Protected AI Execution Finality October 2026
First, the AI workload prepares an outbound request.
Second, the request is intercepted and maintained in a Non-Effective
State.
Third, the Candidate Act Descriptor is constructed.
Fourth, the PED validates workload identity, execution-context
measurement, operation scope, current protected policy state, and
designated hardware egress boundary.
Fifth, required protected-state and evidence conditions are
completed.
Sixth, the scoped execution capability becomes available.
Seventh, the DPU, SmartNIC, or protected gateway obtains the actual
outbound operation and verifies the capability.
Eighth, the hardware-associated Finality Sink permits the bounded
transmission only when mandatory authorization conditions succeed.
Ninth, the protected capability usage state is advanced or consumed
as required.
An unauthorized source workload or incompatible policy version causes
denial even if the packet can otherwise be routed through the cloud
network.
11.22.26. WF-22.26 — Identification of Runtime Transitions
in the implementation described by enforcement point 94, MG-2218
detects or coordinates:
(a) virtual-machine migration;
(b) container replacement;
(c) workload rescheduling;
(d) checkpoint restoration;
(e) cloud-region failover;
(f) node restart;
(g) execution-host replacement; or
Das Expires 19 April 2027 [Page 916]
Internet-Draft Protected AI Execution Finality October 2026
(h) another relevant runtime transition.
The transition may alter the workload identity, execution-context
measurement, or protected deployment epoch.
The protected system determines which attributes have changed and
whether any outstanding authorization remains applicable.
Migration alone does not prove that an authorization is invalid.
However, migration also does not automatically preserve authority
when a mandatory identity, measurement, state, or deployment binding
has changed.
11.22.27. WF-22.27 — Runtime-Transition State Record
An illustrative runtime-transition record comprises:
transition_id;
workload_id;
source_instance_id;
destination_instance_id;
source_substrate;
destination_substrate;
source_measurement;
destination_measurement;
previous_deployment_epoch;
new_deployment_epoch;
current_authorization_version;
pending_candidate_act_references;
capability_state_reference;
transition_status;
protected_authentication.
Das Expires 19 April 2027 [Page 917]
Internet-Draft Protected AI Execution Finality October 2026
The record supports protected evaluation of outstanding operations
following the runtime transition.
The system does not rely exclusively upon the restored workload's
local view of its former authorization state.
11.22.28. WF-22.28 — Migration of Pending Candidate Acts
An AI workload may have prepared a consequential operation before
migration.
The operation may remain queued or otherwise non-effective.
Following a relevant runtime transition, the system determines
whether the operation remains associated with a valid execution
context.
If a mandatory workload identity, measurement, deployment epoch, or
protected policy condition has changed, the pending Candidate Act is
revalidated before effectuation.
The revalidation obtains the current required context and evaluates
the applicable Authority Object.
A capability bound to incompatible earlier conditions does not
independently authorize the pending operation after the transition.
The corresponding Finality Sink enforces the current protected
context before permitting the effect.
11.22.29. WF-22.29 — Runtime Migration Revalidation Predicate
An illustrative migration predicate is:
Vtransition =
WorkloadIdentityValid AND
MeasurementValid AND
DeploymentEpochValid AND
AuthorizationVersionValid AND
CandidateActAuthorityValid
where:
Das Expires 19 April 2027 [Page 918]
Internet-Draft Protected AI Execution Finality October 2026
WorkloadIdentityValid verifies the executing workload after
transition;
MeasurementValid verifies required new runtime measurements;
DeploymentEpochValid verifies the protected deployment generation;
AuthorizationVersionValid verifies applicable current policy and
authority state; and
CandidateActAuthorityValid verifies the operation-specific authority
under the changed context.
Where a pending Candidate Act no longer satisfies its mandatory
authorization conditions, the previous capability is rejected or a
renewed protected authorization procedure is required.
The operation remains non-effective until the required Finality Sink
verification succeeds.
11.22.30. WF-22.30 — Snapshot and Checkpoint Restoration
A snapshot may preserve:
(a) AI-agent memory;
(b) pending tool requests;
(c) cached policy data;
(d) earlier workload identity references;
(e) previously issued capability representations;
(f) task execution state;
(g) model context;
(h) local nonce records; and
(i) previously observed operation outcomes.
Restoration of the snapshot does not restore authoritative protected
authorization state.
The recovered workload is evaluated against the current workload
identity, required measurement, policy version, deployment epoch,
nonce state, and capability usage conditions.
Das Expires 19 April 2027 [Page 919]
Internet-Draft Protected AI Execution Finality October 2026
Where a single-use capability was consumed before the snapshot was
restored, it remains consumed according to the authoritative
protected state.
11.22.31. WF-22.31 — Protected Capability-Consumption State Across
Migration
RS-2219 maintains authoritative capability-consumption information
independently of rollback-accessible workload memory or snapshots.
An illustrative record comprises:
capability_id;
candidate_act_digest;
workload_identity;
authorization_state_version;
deployment_epoch;
remaining_uses;
nonce_state;
revocation_state;
effectuation_status;
protected_state_version.
The storage may be implemented through protected external state, a
trusted state service, a hardware-backed counter, or another suitable
mechanism.
The selected mechanism must preserve the properties required under
the stated threat model.
Restoring a VM, container filesystem, or local agent-state backup
does not automatically reset the authoritative remaining-use count.
11.22.32. WF-22.32 — Duplicate Effectuation Prevention During Failover
A cloud-region failover may occur after a consequential operation was
dispatched but before the originating workload received its result.
Das Expires 19 April 2027 [Page 920]
Internet-Draft Protected AI Execution Finality October 2026
The recovered workload may therefore be uncertain whether the
operation completed.
The system distinguishes:
(a) an operation known not to have become effective;
(b) a confirmed effective operation; and
(c) an indeterminate operation.
The recovered agent does not automatically repeat the same
consequential operation merely because its application-level state
indicates that no response was received.
The protected recovery mechanism consults available effectuation
evidence, protected capability state, and receiving-side status where
supported.
A renewed attempt is processed under the required current
authorization and duplicate-prevention conditions.
The architecture does not presume that a local capability-consumption
record can, by itself, establish exactly-once completion at every
remote service.
11.22.33. WF-22.33 — Failover State-Reconciliation Procedure
A non-limiting recovery procedure comprises:
First, identify the recovered workload and destination execution
substrate.
Second, establish the authenticated workload identity and required
current measurement.
Third, obtain the applicable current protected authorization-state
version.
Fourth, determine whether the workload's deployment epoch has
changed.
Fifth, retrieve authoritative capability-consumption and revocation
state.
Sixth, enumerate pending or interrupted Candidate Acts.
Das Expires 19 April 2027 [Page 921]
Internet-Draft Protected AI Execution Finality October 2026
Seventh, distinguish confirmed-effective, non-effective, and
indeterminate operations.
Eighth, revalidate each pending Candidate Act whose mandatory context
changed.
Ninth, reject stale, consumed, or incompatible capabilities.
Tenth, permit any authorized resumed effectuation only after the
applicable Finality Sink independently verifies current authority.
This procedure prevents recovery from being used as an uncontrolled
replay mechanism.
11.22.34. WF-22.34 — Model-Access Authorization
in the implementation described by enforcement point 95, MC-2220
governs access to a local or remote artificial-intelligence model.
The component may validate:
(a) requesting workload identity;
(b) model identity;
(c) approved model configuration;
(d) computation purpose;
(e) relevant policy state;
(f) applicable session authority; and
(g) model-access validity.
Successful model-access authorization permits the corresponding
approved computation within its authorized scope.
It does not independently authorize a consequential operation
produced by the model.
The system therefore preserves the distinction between a model-access
control decision and a downstream execution-finality decision.
11.22.35. WF-22.35 — Separate Downstream Operation Authorization
An admitted model may generate:
Das Expires 19 April 2027 [Page 922]
Internet-Draft Protected AI Execution Finality October 2026
(a) an API request;
(b) a network transmission;
(c) a protected tool operation;
(d) a database mutation;
(e) a credential-mediated instruction;
(f) a payment request;
(g) a software deployment; or
(h) another consequential Candidate Act.
The operation remains subject to the applicable downstream protected
finality requirements.
A separate operation-specific execution capability is required when
the corresponding effectuation boundary is governed by enforcement
point 95.
The downstream Finality Sink independently verifies that capability.
The model-access gate does not replace the Finality Sink.
11.22.36. WF-22.36 — Interruption or Revocation of Future Model Access
The model-access component may interrupt, quarantine, or revoke
further model access.
However, a Candidate Act may already have been generated and retained
in a buffer.
The interruption of future inference does not authorize release of
the previously generated operation.
The buffered Candidate Act remains non-effective until its separately
required execution capability verifies at the downstream Finality
Sink.
Where the protected policy also revokes the downstream authority, the
Finality Sink enforces that revocation.
The system does not presume that model-path interruption itself
retroactively prevents a downstream operation already completed.
Das Expires 19 April 2027 [Page 923]
Internet-Draft Protected AI Execution Finality October 2026
11.22.37. WF-22.37 — Illustrative Cross-Cloud Migration
An AI agent executes in Cloud Region A.
The agent prepares a request to update a protected enterprise record.
The request is intercepted and retained in a Non-Effective State.
A workload identity and execution-context measurement are associated
with the pending Candidate Act.
Before effectuation, the orchestrator migrates or reinstantiates the
agent in Cloud Region B.
The new instance has a changed workload-instance identity and
deployment epoch.
The protected system evaluates the new authenticated workload context
and current authorization-state version.
The pending Candidate Act is revalidated where the changed context
affects mandatory authorization.
A prior capability bound to an incompatible workload identity or
deployment epoch is rejected.
Following successful new authorization, the appropriate Finality Sink
verifies the current operation-specific capability before the record
update is permitted.
The workload migration does not itself carry unrestricted execution
authority into the new environment.
11.22.38. WF-22.38 — Illustrative Kubernetes Replica Policy Update
An AI-agent service executes through several Kubernetes replicas.
A protected policy update revokes permission to transmit data to a
specified external endpoint.
PV-2217 advances the authorization-state version applicable to the
defined replica scope.
One replica has not yet refreshed its local application-level policy
cache.
Das Expires 19 April 2027 [Page 924]
Internet-Draft Protected AI Execution Finality October 2026
It submits a previously prepared outbound request and presents a
capability bound to an incompatible earlier authorization-state
version.
The cloud network Finality Sink checks the required current protected
version.
The capability is rejected.
The operation remains non-effective despite the replica's stale local
policy view.
The result depends upon the Finality Sink having access to
sufficiently current protected authorization state under the
specified version-enforcement model.
11.22.39. WF-22.39 — Illustrative SmartNIC-Supervised Agent Egress
An AI agent runs within a virtualized cloud compute environment.
The workload has valid cloud-network identity and can prepare an
HTTPS request.
The actual outbound interface is controlled by a SmartNIC-associated
Finality Sink.
The PED validates the Candidate Act against its source workload,
measured execution context, destination, operation type, current
authorization-state version, and required policy.
A scoped capability becomes available.
The SmartNIC verifies the capability against the actual operation and
authenticated workload context.
Only the authorized outbound request is admitted.
The ability to establish a virtual network interface or authenticated
cloud session does not independently permit unverified network
effectuation.
11.22.40. WF-22.40 — Illustrative Snapshot Replay
An AI workload receives a single-use capability for one protected
external operation.
The operation is performed and the capability is consumed.
Das Expires 19 April 2027 [Page 925]
Internet-Draft Protected AI Execution Finality October 2026
The workload is then restored from a snapshot created before
execution.
The restored workload contains the earlier capability representation.
However, the authoritative protected capability-consumption state
records that the grant is already consumed.
The restored workload attempts to repeat the operation.
The downstream Finality Sink consults the required current state and
refuses reuse.
Snapshot restoration does not revive previously consumed execution
authority.
11.22.41. WF-22.41 — Illustrative Model-Path and Effectuation-Path
Separation
An AI agent obtains valid access to a remote model and produces a
proposed network transmission.
The model-access component authorizes the inference.
The generated transmission is classified as a Candidate Act and held
in a Non-Effective State.
A security component subsequently interrupts further model access.
The buffered transmission remains pending.
The downstream network Finality Sink requires a separately valid
operation-specific execution capability.
If the required capability is absent or invalid, the transmission is
refused.
The previous successful model call does not authorize the
transmission, and the model interruption does not itself discharge
downstream verification.
11.22.42. WF-22.42 — Time-of-Check and Time-of-Use Protection
The protected system preserves the relationship between the Candidate
Act originally authorized and the operation actually presented at the
Finality Sink.
Potential changes include:
Das Expires 19 April 2027 [Page 926]
Internet-Draft Protected AI Execution Finality October 2026
(a) workload instance substitution;
(b) VM migration;
(c) container image replacement;
(d) policy update;
(e) destination substitution;
(f) payload modification;
(g) protected deployment-epoch change;
(h) different Finality Sink;
(i) revoked workload identity; or
(j) restored authorization state.
The Finality Sink verifies the actual operation and current mandatory
context.
Where exact correspondence is required, incompatible changes cause
rejection.
Where an Authority Object expressly permits bounded migration or
workload-equivalent scope, verification follows those defined
conditions.
Portability is therefore governed by authenticated authority rather
than unrestricted transfer of a previously issued capability.
11.22.43. WF-22.43 — Fail-Closed Runtime Policy Handling
The system refuses the affected consequential operation when
mandatory current authorization information is unavailable.
Examples include:
(a) inability to verify the executing workload identity;
(b) missing required execution measurement;
(c) unavailable current authorization-state version;
(d) stale or revoked policy state;
Das Expires 19 April 2027 [Page 927]
Internet-Draft Protected AI Execution Finality October 2026
(e) failed capability authentication;
(f) invalid deployment epoch;
(g) consumed nonce;
(h) unavailable Finality Sink verification; or
(i) inconsistent protected recovery state.
The system may retain the Candidate Act pending authorized recovery
or revalidation.
It does not automatically substitute an earlier cached policy result
when the current required authorization state cannot be established.
11.22.44. WF-22.44 — Alternative Technical Implementations
Container implementation: A protected runtime identity and execution-
capability mechanism govern operations across container deployment
and replacement.
Virtual-machine implementation: Workload authority is bound to the
required VM identity, measurement, and policy state.
Confidential-VM implementation: Hardware-backed attestation
contributes authenticated execution-context evidence while downstream
Candidate Act authority remains separately enforced.
Kubernetes implementation: Replicated workloads share an expressly
defined protected authorization-state scope, with version checks at
affected Finality Sinks.
On-premises implementation: A locally protected host controller or
gateway governs operations without requiring a particular public
cloud.
Hybrid-cloud implementation: Workload authority is validated across
authenticated cloud and on-premises execution environments.
Multi-region implementation: Failover reestablishes the required
workload context and protected authorization state before pending
operations are released.
SmartNIC/DPU implementation: Hardware-associated network egress
enforces the operation-specific capability independently of cloud
connectivity.
Das Expires 19 April 2027 [Page 928]
Internet-Draft Protected AI Execution Finality October 2026
Service-mesh implementation: A protected proxy verifies the scoped
capability before permitting a governed service operation.
Accelerator implementation: An accelerator-egress controller enforces
the required capability before protected data export.
Single-node implementation: The PED and Finality Sink may reside
within one protected host while maintaining their distinct
authorization and effectuation-verification functions.
Distributed implementation: Protected authority and Finality Sink
services operate on separate nodes using authenticated capability and
state information.
The implementation must establish its own workload identity,
protected-state continuity, revocation, migration, and path-coverage
guarantees.
11.22.45. WF-22.45 — Failure and Fail-Closed Conditions
The system withholds effectuation when a mandatory condition is
invalid, absent, inconsistent, expired, revoked, replayed, or
unverifiable.
Non-limiting conditions include:
(a) unauthorized execution substrate;
(b) invalid workload identity;
(c) incompatible workload measurement;
(d) unapproved container image;
(e) invalid VM launch measurement;
(f) agent runtime identity mismatch;
(g) tool-policy digest mismatch;
(h) model configuration mismatch;
(i) protected execution-policy mismatch;
(j) unauthorized Candidate Act;
(k) destination or operation-scope violation;
Das Expires 19 April 2027 [Page 929]
Internet-Draft Protected AI Execution Finality October 2026
(l) incompatible authorization-state version;
(m) stale policy epoch;
(n) revoked workload grant;
(o) invalid deployment epoch;
(p) migration-context mismatch;
(q) snapshot-restored nonce;
(r) consumed execution capability;
(s) failed mandatory protected-state transition;
(t) failed required validation-evidence commitment;
(u) missing scoped capability;
(v) invalid capability authentication;
(w) unauthorized Finality Sink;
(x) cloud egress context mismatch;
(y) failed required hardware verification;
(z) attempted unauthorized duplicate effectuation; or
(aa) unavailable mandatory effectuation-boundary enforcement.
Failure of workload deployment, policy synchronization, or runtime
recovery does not create unrestricted execution authority.
11.22.46. WF-22.46 — PHOSITA Verification and Negative Tests
A person having ordinary skill in cloud computing, virtual-machine
security, container orchestration, distributed authorization,
SmartNIC/DPU enforcement, confidential computing, and protected AI
execution may verify the architecture through controlled tests.
Test 1 — Authorized cloud operation: Deploy an approved workload and
submit a Candidate Act satisfying all required authorization
conditions. The Finality Sink permits the scoped effect.
Das Expires 19 April 2027 [Page 930]
Internet-Draft Protected AI Execution Finality October 2026
Test 2 — Invalid workload identity: Present a capability through a
different unauthorized workload. Required identity verification
fails.
Test 3 — Container image substitution: Change a mandatory approved
image digest. The protected authorization is refused.
Test 4 — VM measurement mismatch: Present an incompatible VM
measurement. Required measurement verification fails.
Test 5 — Tool-policy modification: Alter a mandatory approved tool-
policy digest. The Candidate Act cannot use a capability bound to
the earlier condition.
Test 6 — Model configuration substitution: Change the required model
configuration. Protected authorization fails where the changed
measurement is mandatory.
Test 7 — Missing execution capability: Provide valid workload
authentication without an operation-specific capability. The
Finality Sink refuses effectuation.
Test 8 — Unauthorized destination: Substitute a destination outside
the capability scope. Actual-operation verification fails.
Test 9 — Replica policy update: Advance a protected authorization
version while a replica retains older policy state. The affected
Finality Sink rejects incompatible earlier capabilities.
Test 10 — Stale replica restart: Restart a workload under an obsolete
authorization-state version. The new consequential operation remains
subject to current-state verification.
Test 11 — Container replacement: Replace the executing container and
attempt to reuse a capability bound to an incompatible previous
identity or measurement. Verification fails.
Test 12 — VM migration: Move the workload to another VM and
revalidate pending Candidate Acts under the changed mandatory
context.
Test 13 — Cloud-region failover: Recover the workload in another
region without automatically restoring stale effectuation authority.
Test 14 — Snapshot rollback: Restore an earlier snapshot containing a
consumed capability. The Finality Sink rejects the replay.
Das Expires 19 April 2027 [Page 931]
Internet-Draft Protected AI Execution Finality October 2026
Test 15 — Concurrent replica execution: Submit competing effects
under one restricted authorization grant. Protected state prevents
unauthorized duplicate consumption.
Test 16 — Failover after uncertain completion: Simulate an operation
that may have completed before failover. Recovery preserves
indeterminate state and avoids unauthorized automatic repetition.
Test 17 — Hardware cloud egress: Present a capability to a protected
SmartNIC/DPU controller and verify bounded operation-specific
enforcement.
Test 18 — Cloud authentication without capability: Successfully
authenticate the workload to the cloud network but omit the execution
capability. The governed transmission is refused.
Test 19 — Wrong Finality Sink: Present a capability issued for one
gateway or interface at another unauthorized sink. Required sink
binding fails.
Test 20 — Policy-version rollback: Attempt to restore an obsolete
protected authorization-state version. The required protected-state
mechanism rejects incompatible authority.
Test 21 — Revocation during migration: Revoke a mandatory operation
permission while the workload changes execution substrate. The
subsequent effectuation remains blocked.
Test 22 — Missing policy service: Make the required current protected
policy state unavailable. The Finality Sink refuses the affected
operation.
Test 23 — Model-access authorization only: Admit a model computation
without issuing downstream operation-specific authority. The
consequential operation remains non-effective.
Test 24 — Model-path quarantine: Interrupt future inference after a
Candidate Act is buffered. The downstream Finality Sink continues to
enforce its authorization independently.
Test 25 — Service-mesh bypass: Attempt the governed effect through an
alternative available service or network path. The implementation
blocks or equivalently mediates it.
Test 26 — On-premises to cloud migration: Move an agent from an on-
premises host into a cloud VM and validate current workload identity,
measurement, and policy state.
Das Expires 19 April 2027 [Page 932]
Internet-Draft Protected AI Execution Finality October 2026
Test 27 — Single-node enforcement: Implement PED and Finality Sink
functions within one host while preserving mandatory operation-
specific verification.
Test 28 — Distributed enforcement: Verify protected authorization at
one node and effectuation at another, using current authenticated
operation and policy state.
Test 29 — Stale capability after redeployment: Reinstantiate an agent
under a new protected deployment epoch and attempt an incompatible
earlier capability. Verification fails.
Test 30 — Capability-consumption continuity: Verify that protected
usage state is preserved across restart, migration, and failover.
Test 31 — Actual operation mutation: Alter mandatory operation
parameters after authorization. The Finality Sink refuses the
changed operation.
Test 32 — Recovery of valid pending act: Restore a pending operation
under a current valid execution context and perform the required
revalidation before effectuation.
Test 33 — Independent receiving-side consequence: Authorize network
transmission but withhold separately required database-commit
authority. The downstream commit remains blocked.
Test 34 — Confirmed effect versus attempted effect: Simulate a
successful capability verification without confirmed remote
completion. Preserve the distinction between authorization and
completed outcome.
The tests may use Kubernetes clusters, container runtimes,
confidential-VM fixtures, multi-region cloud simulators,
authenticated workload identity services, protected authorization
stores, programmable SmartNIC/DPU interfaces, mock downstream
services, snapshot tooling, and fault injection.
The results establish only the properties actually demonstrated by
the implementation and its defined threat model.
11.22.47. WF-22.47 — Claim-Specific Technical Support
Enforcement Point 90 — Portable Cloud-VM Agent Authority and Hardware
Effectuation System
WF-22.2 through WF-22.20 describe:
Das Expires 19 April 2027 [Page 933]
Internet-Draft Protected AI Execution Finality October 2026
(a) the agent-execution control plane;
(b) deployment across cloud and virtualized substrates;
(c) authenticated workload identity and execution-context
measurement;
(d) Protected Enforcement Domain maintenance of authorization-state
versions and execution-policy predicates;
(e) Candidate Act interception and Non-Effective State holding;
(f) protected act-specific validation;
(g) cryptographically scoped capability issuance;
(h) independent verification by a designated host, VM, cloud gateway,
service-mesh, protected connector, SmartNIC, DPU, or accelerator
Finality Sink; and
(i) prevention of automatic restoration of stale or incompatible
execution authority following redeployment or recovery.
Enforcement Point 91 — VM and Container Identity Attestation
WF-22.5 through WF-22.7 describe validation of workload image digest,
VM launch measurement, container image identity, runtime identity,
tool-policy digest, model configuration digest, and applicable
protected policy state.
Capabilities are rejected when mandatory workload identity or
measurement does not correspond to the actual executing instance.
Enforcement Point 92 — Runtime Policy Changes Across Cloud Replicas
WF-22.21 through WF-22.23 describe protected authorization-state
version advancement across defined workload scopes and rejection of
capabilities bound to incompatible previous versions.
Enforcement Point 93 — Hardware-Supervised Cloud Egress
WF-22.24 and WF-22.25 describe SmartNIC, DPU, protected network
gateway, or hardware-assisted egress enforcement and distinguish
ordinary network authentication from operation-specific execution
authority.
Enforcement Point 94 — Cross-Runtime Migration and Snapshot
Protection
Das Expires 19 April 2027 [Page 934]
Internet-Draft Protected AI Execution Finality October 2026
WF-22.26 through WF-22.33 describe runtime migration, container
replacement, rescheduling, checkpoint restoration, region failover,
changed workload context, pending Candidate Act revalidation,
capability-consumption continuity, and duplicate-effectuation
protection.
Enforcement Point 95 — Model-Path Authorization Does Not Replace
Effectuation Authorization
WF-22.34 through WF-22.36 describe separate model-access and
downstream effectuation authorization.
Successful inference admission does not grant an operation-specific
capability, and interruption or quarantine of future model access
does not permit release of a buffered, unverified Candidate Act.
11.22.48. WF-22.48 — Technical Effect
The workflow establishes protected operation-specific authority that
remains valid only under the actual authorized workload, execution
context, policy version, and Finality Sink requirements.
The protected sequence comprises:
(a) deployment or reinstantiation of an AI workload on a supported
execution substrate;
(b) establishment of authenticated workload identity;
(c) machine-verifiable execution-context measurement;
(d) protected registration of applicable workload authority and
authorization-state version;
(e) generation of a consequential Candidate Act;
(f) interception and Non-Effective State staging;
(g) construction of the effectuation-relevant operation descriptor;
(h) protected validation of the actual operation, workload,
measurement, and current authorization state;
(i) required protected-state and validation-evidence handling;
(j) generation or availability of a cryptographically scoped
execution capability;
Das Expires 19 April 2027 [Page 935]
Internet-Draft Protected AI Execution Finality October 2026
(k) independent Finality Sink verification;
(l) controlled effectuation or fail-closed withholding;
(m) authorization-version advancement across affected replicas;
(n) revalidation after relevant migration or runtime changes;
(o) continuity of protected consumption and revocation state across
snapshots and failover; and
(p) continued separation of model-access permission from downstream
execution authority.
The architecture prevents cloud workload portability from becoming a
mechanism for restoring stale or consumed authority.
The replica policy-version mechanism prevents incompatible earlier
permissions from governing new operations where current-version
checks are mandatory.
The hardware-egress embodiment prevents ordinary cloud connectivity
from substituting for the required protected execution-capability
verification.
The migration and recovery embodiment maintains operation-specific
authorization across runtime transitions without assuming
unconditional exactly-once completion of arbitrary external systems.
Computation is not authority to act.
Workload portability is not automatic portability of execution
authority.
Cloud identity is not operation-specific authorization.
A restarted or restored workload must not revive stale or consumed
capabilities.
Authorization to access a model is not authorization to execute a
model-generated operation.
The actual Finality Sink verifies the authority applicable to the
consequential effect.
Das Expires 19 April 2027 [Page 936]
Internet-Draft Protected AI Execution Finality October 2026
11.23. WF-23 — Atomic Protected-State Consumption, Validation-Evidence
Commitment, Non-Bearer Capability Replay Prevention, Crash-
Consistent Finality, and Duplicate-Effect Recovery
11.23.1. WF-23.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture for maintaining the consistency, ordering,
freshness, consumption, and recovery of authorization state
associated with consequential operations generated by artificial-
intelligence agents or other computational workloads.
The architecture addresses circumstances in which a Candidate Act is
validly proposed but must not become effective unless the required
protected authorization sequence is completed.
The system prevents a previously issued grant, capability, validation
receipt, or authorization decision from enabling an unauthorized
additional consequential effect through replay, concurrent use, stale
state, interrupted commitment, process failure, communication
timeout, virtual-machine restoration, or recovery.
A proposed consequential operation is classified as a Candidate Act
and maintained in a Non-Effective State.
The applicable Protected Enforcement Domain validates the operation
against the required Authority Object, execution context, current
authorization state, freshness, revocation, and Finality Sink
conditions.
Where the applicable embodiment requires an Atomic Protected-State
Transition, required authorization-state updates are committed with
the consistency and ordering necessary to prevent unauthorized
effectuation.
Where the embodiment requires Atomic State Consumption and Atomic
Finality Commit, the protected authorization-state update,
validation-evidence commitment, and capability availability are
coordinated as a protected finality transaction.
The operation-specific capability becomes usable only when the
mandatory protected dependencies succeed.
The designated Finality Sink independently verifies the capability
against the actual Candidate Act and applicable current protected
state immediately before permitting the operation.
Das Expires 19 April 2027 [Page 937]
Internet-Draft Protected AI Execution Finality October 2026
The protected system maintains distinguishable states for
authorization, reservation, attempted effectuation, confirmed
completion, denial, revocation, and indeterminate outcome.
A retry after timeout, crash, or communication failure is correlated
with the original Candidate Act and protected authorization state.
Uncertainty about an earlier external effect does not independently
authorize a second execution.
This embodiment further distinguishes local prevention of
unauthorized capability reuse from exactly-once delivery or
completion across arbitrary external systems.
11.23.2. WF-23.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
AE-2301 — AI Execution Environment
An artificial-intelligence agent, autonomous process, model runtime,
tool environment, sandbox, confidential workload, or other
computational component configured to generate Candidate Acts.
IM-2302 — Candidate Act Interception Component
A mandatory enforcement-controlled mechanism configured to intercept
a proposed consequential operation before the applicable execution-
finality boundary.
HQ-2303 — Non-Effective Candidate Act Holding Mechanism
A controlled queue, buffer, staged command, inactive transaction
request, or equivalent mechanism preventing the operation from
becoming effective before required authorization.
DC-2304 — Candidate Act Descriptor Component
A component configured to construct or verify the canonical, machine-
readable representation of the actual proposed operation.
PED-2305 — Protected Enforcement Domain
A protected authority component configured to validate the Candidate
Act and coordinate the required authorization-state transition,
evidence commitment, and capability availability.
Das Expires 19 April 2027 [Page 938]
Internet-Draft Protected AI Execution Finality October 2026
AS-2306 — Protected Authority Store
An authenticated source of Authority Objects, permitted operation
classes, grant restrictions, execution scope, policy epochs, and
revocation information.
GS-2307 — Protected Grant-State Store
A protected mechanism maintaining active grants, authorized
operations, permitted usage counts, validity intervals, reserved
authorizations, and revocation state.
TX-2308 — Atomic Protected-State Transaction Component
A mechanism configured to perform required authorization-state
operations with the ordering and consistency necessary to prevent
unauthorized effectuation from incomplete or inconsistent state
handling.
EV-2309 — Protected Validation-Evidence Component
A mechanism configured to generate or commit the required validation
receipt, LAVR, AVR, authenticated state commitment, or equivalent
evidence.
CR-2310 — Scoped Execution-Capability Mechanism
A protected component configured to prepare, issue, register,
activate, release, or otherwise make available a scoped, non-bearer
execution capability.
CS-2311 — Protected Capability-Consumption Store
A mechanism maintaining protected capability usage, nonce state,
authorization generations, consumption reservations, and replay-
prevention information.
FS-2312 — Finality Sink
An execution-controlled network, credential, tool, storage,
financial, hardware, API, or other effectuation boundary configured
to verify the required capability before completing the governed
effect.
OC-2313 — Protected Operation-State Controller
A mechanism maintaining the formal execution-finality state of each
Candidate Act.
Das Expires 19 April 2027 [Page 939]
Internet-Draft Protected AI Execution Finality October 2026
OS-2314 — Protected Effectuation-Outcome Store
A protected mechanism maintaining whether an operation is pending,
reserved, denied, confirmed effective, or of indeterminate completion
status.
RC-2315 — Protected Recovery Controller
A component configured to coordinate recovery after crashes,
timeouts, process restarts, communication failures, and other
interrupted execution-finality procedures.
DR-2316 — Duplicate-Effect Prevention Component
A mechanism configured to correlate repeated execution attempts with
the original operation and enforce the applicable consumption and
retry restrictions.
RV-2317 — Protected Revocation and Epoch Controller
A component configured to maintain or verify current required
authorization epochs, revocation state, and protected execution
generations.
HF-2318 — Optional Hardware Freshness Component
A trusted counter, hardware sequence, secure boot epoch, protected
clock, or corresponding mechanism supporting freshness and rollback
resistance where required.
RR-2319 — Optional Receiving-Side Reconciliation Component
An authenticated remote operation-status, idempotency, or completion-
evidence interface used when supported by the external receiving
system.
SC-2320 — Protected State-Consistency Component
A mechanism configured to maintain or verify the required
correspondence among the Candidate Act, grant, validation receipt,
capability, Finality Sink, and effectuation outcome.
The components may be integrated within a protected node or
distributed across authenticated components.
The same physical component may perform several roles without
eliminating the required authorization dependencies.
Das Expires 19 April 2027 [Page 940]
Internet-Draft Protected AI Execution Finality October 2026
11.23.3. WF-23.3 — Establishment of the Protected Authorization
Boundary
The architecture establishes a protected boundary between the AI
execution environment and the authority required to complete
consequential operations.
AE-2301 may:
(a) generate requests;
(b) prepare commands;
(c) create transaction parameters;
(d) calculate operation descriptors;
(e) invoke permitted computational tools;
(f) submit proposed operations; or
(g) receive authorization or completion status.
However, AE-2301 cannot unilaterally:
(a) modify protected grant-consumption state;
(b) mark a consumed capability as unused;
(c) fabricate a valid protected validation commitment;
(d) advance or reverse protected authorization epochs;
(e) override mandatory Finality Sink verification;
(f) authorize unrestricted duplicate execution;
(g) convert an interrupted operation into an authorized retry; or
(h) restore previously invalidated authority merely by restarting its
process.
The protected state mechanism is isolated from the requesting
workload's unilateral control under the applicable threat model.
The Finality Sink enforces the required capability-dependent
conditions at the actual governed effectuation boundary.
Das Expires 19 April 2027 [Page 941]
Internet-Draft Protected AI Execution Finality October 2026
11.23.4. WF-23.4 — Distinguishing Authorization from Effectuation
The architecture distinguishes at least the following events.
Validation: The protected authority determines that the proposed
Candidate Act satisfies its required predicates.
State reservation or consumption: Protected authorization state is
advanced, reserved, or consumed according to the applicable usage
conditions.
Validation-evidence commitment: Required protected evidence of
successful authorization is established.
Capability availability: The scoped execution capability becomes
valid and available for the designated operation.
Finality Sink verification: The actual effectuation interface
independently verifies the capability and required current state.
Effectuation: The consequential operation crosses the governed
execution-finality boundary.
Outcome confirmation: Evidence establishes whether the specified
effect completed under the applicable completion semantics.
These events may be coordinated closely or implemented through a
protected transactional procedure.
However, they are not automatically identical.
In particular, successful authorization does not itself establish
completion of an external effect.
Likewise, capability preparation does not independently authorize
effectuation when mandatory protected commitment or Finality Sink
verification remains incomplete.
11.23.5. WF-23.5 — Candidate Act Generation
AE-2301 generates a proposed consequential operation.
The operation may comprise:
(a) a network transmission;
(b) an external API invocation;
Das Expires 19 April 2027 [Page 942]
Internet-Draft Protected AI Execution Finality October 2026
(c) a credential-mediated request;
(d) a protected file modification;
(e) a database commit;
(f) a message publication;
(g) a financial transaction;
(h) an accelerator transfer;
(i) a software deployment; or
(j) another governed consequential operation.
The proposed operation is classified as Candidate Act CA-2321.
The Candidate Act has an identity distinct from any particular
execution attempt.
This distinction permits multiple observations or recovery attempts
to be associated with one protected operation without automatically
granting additional effectuation authority.
11.23.6. WF-23.6 — Candidate Act Identifier and Attempt Identifier
In one implementation, the system maintains:
candidate_act_id;
attempt_id;
operation_descriptor_digest;
source_workload_identity;
authorized_operation_scope;
finality_sink_identity.
The Candidate Act identifier represents the governed consequential
operation.
An attempt identifier represents one submission or attempted
effectuation of that operation.
Das Expires 19 April 2027 [Page 943]
Internet-Draft Protected AI Execution Finality October 2026
Several attempt identifiers may refer to one Candidate Act when
communication retries or recovery procedures occur.
Such association does not authorize multiple external effects.
The protected system evaluates the existing authorization and outcome
state before permitting another attempt.
A retry is not treated as an unrelated new Candidate Act merely
because the requesting workload generates a new transport request or
application-level identifier.
11.23.7. WF-23.7 — Interception and Non-Effective State
IM-2302 intercepts CA-2321 before the applicable effectuation
boundary.
HQ-2303 retains the operation in a Non-Effective State.
An illustrative staged operation record comprises:
candidate_act_id;
operation_class;
requesting_workload;
target_resource;
destination;
payload_reference;
descriptor_reference;
policy_epoch;
grant_reference;
finality_sink_id;
status = NON_EFFECTIVE.
The operation remains unable to complete the governed effect until
required protected authorization and Finality Sink verification
succeed.
Das Expires 19 April 2027 [Page 944]
Internet-Draft Protected AI Execution Finality October 2026
The system does not treat successful queue insertion as execution
permission.
11.23.8. WF-23.8 — Canonical Candidate Act Descriptor
DC-2304 constructs a canonical machine-readable representation of CA-
2321.
The descriptor may identify:
(a) Candidate Act identity;
(b) operation class;
(c) requesting workload;
(d) destination or recipient;
(e) resource identifier;
(f) effectuation-relevant parameters;
(g) payload digest;
(h) applicable authority and grant;
(i) protected policy epoch;
(j) authorization-state version;
(k) nonce and expiry; and
(l) designated Finality Sink.
An illustrative representation is:
Dact = Canon_v(ID, ACT, SOURCE, TARGET, PARAM, AUTH, EPOCH, NONCE,
SINK)
where the fields represent the corresponding Candidate Act,
operation, source, destination, parameters, authorization context,
protected state version, freshness, and Finality Sink.
An illustrative digest is:
hAct = H("DAS-ATOMIC-FINALITY-ACT-v1" || Encode(Dact))
Das Expires 19 April 2027 [Page 945]
Internet-Draft Protected AI Execution Finality October 2026
The deterministic encoding must preserve distinctions that affect the
relevant authorization.
The particular hash function, field order, and serialization format
are implementation choices.
11.23.9. WF-23.9 — Protected Grant-State Record
in the implementation described by enforcement point 20, GS-2307
maintains a protected authorization-state record identifying:
(a) an active grant;
(b) authorized operation;
(c) validity interval;
(d) permitted usage count; and
(e) revocation state.
An illustrative record comprises:
grant_id;
authority_object_id;
authorized_operation_class;
authorized_candidate_act_scope;
valid_from;
valid_until;
remaining_uses;
reserved_uses;
revocation_state;
policy_epoch;
authorization_state_version;
protected_authentication.
Das Expires 19 April 2027 [Page 946]
Internet-Draft Protected AI Execution Finality October 2026
The protected record determines whether the grant can support the
proposed consequential operation.
Possession of a copy of a grant identifier does not independently
establish that the grant remains usable.
11.23.10. WF-23.10 — Grant Eligibility Verification
PED-2305 evaluates the applicable grant.
The required conditions may include:
(a) grant authenticity;
(b) authorized operation class;
(c) permitted destination;
(d) valid time interval;
(e) current revocation state;
(f) remaining usage allowance;
(g) applicable policy epoch;
(h) required source identity;
(i) Candidate Act Descriptor correspondence; and
(j) intended Finality Sink.
An illustrative predicate is:
Vgrant = AuthenticGrant AND ScopeValid AND TimeValid AND
UsageAvailable AND NotRevoked AND StateValid
If a mandatory condition fails, the grant cannot authorize the
requested consequential operation.
An earlier positive decision does not override current protected
usage or revocation state when those checks are mandatory.
11.23.11. WF-23.11 — Atomic Protected-State Transition
TX-2308 coordinates the required authorization-state changes.
Das Expires 19 April 2027 [Page 947]
Internet-Draft Protected AI Execution Finality October 2026
For an operation requiring single-use consumption, the transition
may:
(a) verify that the grant is active;
(b) verify that its usage allowance is available;
(c) verify the applicable nonce;
(d) reserve or decrement the permitted usage count;
(e) register the Candidate Act identity;
(f) update protected authorization state; and
(g) establish the corresponding protected transition result.
These related state operations are performed with the required
consistency and ordering.
Where an atomic protected-state transition is mandatory, the relevant
updates commit together or fail together.
A failed mandatory transition does not make the corresponding
execution-enabling authority usable.
This atomicity need not encompass the entire remote external service
operation.
11.23.12. WF-23.12 — Concurrency and Double-Consumption Prevention
Two or more execution attempts may concurrently request authority
under the same restricted grant.
An illustrative race comprises:
Attempt A reads remaining_uses = 1.
Attempt B reads remaining_uses = 1.
Both attempts seek to consume the same grant.
A non-atomic check followed by an unprotected update may permit both
attempts to proceed.
The protected system instead uses a suitable atomic state transition,
compare-and-swap operation, transaction, protected serialization
mechanism, or equivalent consistency control.
Das Expires 19 April 2027 [Page 948]
Internet-Draft Protected AI Execution Finality October 2026
Only a number of attempts within the expressly permitted usage
allowance may successfully reserve or consume authority.
When only one consequential effect is authorized, competing
incompatible attempts cannot each obtain independently valid
execution authority.
11.23.13. WF-23.13 — Protected Grant Reservation
In an implementation requiring a reservation before final
effectuation, TX-2308 transitions the grant into a protected reserved
state.
An illustrative transition is:
GRANT_ACTIVE → GRANT_RESERVED_FOR_ACT.
The reservation record may contain:
grant_id;
candidate_act_id;
operation_descriptor_digest;
reservation_id;
reserved_usage;
policy_epoch;
nonce;
finality_sink_id;
reservation_status.
The reservation associates the grant with the specific Candidate Act.
A reservation is not treated as proof that the external operation
completed.
The protected system enforces the applicable rule determining whether
and when a reservation can be released, consumed, retired, or
retried.
Das Expires 19 April 2027 [Page 949]
Internet-Draft Protected AI Execution Finality October 2026
11.23.14. WF-23.14 — Atomic Finality Commit
Where the embodiment requires Atomic Finality Commit, the protected
system coordinates:
(a) successful authority validation;
(b) required grant reservation or consumption;
(c) protected authorization-state update;
(d) required validation-evidence commitment; and
(e) capability availability.
An illustrative protected transaction is:
(Snext, Ract, CapabilityReady) = CommitFinality(Dact, A, Scurrent, F)
where:
Snext denotes the committed protected authorization state;
Ract denotes the corresponding protected validation evidence;
CapabilityReady denotes successful completion of all mandatory pre-
release dependencies;
Dact denotes the validated Candidate Act Descriptor;
A denotes applicable authenticated authority;
Scurrent denotes the prior protected state; and
F denotes the designated Finality Sink.
Where atomic commitment is required, an incomplete mandatory
transaction cannot produce a valid usable capability.
The implementation does not require one globally distributed
transaction encompassing every remote effectuation system.
11.23.15. WF-23.15 — Protected Validation-Evidence Commitment
EV-2309 generates or commits the protected validation evidence
applicable to CA-2321.
An illustrative record comprises:
Das Expires 19 April 2027 [Page 950]
Internet-Draft Protected AI Execution Finality October 2026
receipt_id;
candidate_act_id;
descriptor_digest;
grant_id;
authority_object_reference;
validated_predicate_reference;
protected_state_transition;
consumption_or_reservation_reference;
policy_epoch;
nonce;
finality_sink_id;
authorization_result;
protected_authentication.
The record may comprise a LAVR, AVR, sealed validation record,
authenticated state commitment, or another supported protected
artifact.
Where required, the validation evidence participates in the protected
pre-effectuation dependency rather than being created solely as a
post-event audit log.
A successful post-operation log entry does not establish that
mandatory protected validation evidence existed before capability
availability.
11.23.16. WF-23.16 — Capability Preparation Versus Capability Release
The protected system may prepare a capability representation before
completing all required state or evidence operations.
However, the capability does not become valid or usable for the
governed effect until the mandatory prerequisites succeed.
The system distinguishes:
Das Expires 19 April 2027 [Page 951]
Internet-Draft Protected AI Execution Finality October 2026
CAPABILITY_PREPARED;
CAPABILITY_RELEASED;
CAPABILITY_VALID_AT_SINK;
CAPABILITY_CONSUMED.
A prepared capability may remain sealed, inactive, or otherwise
unavailable.
Where a capability-registration model is used, a protected table
entry does not become active until the required commit condition
succeeds.
An incomplete state transition cannot be bypassed merely because the
cryptographic bytes of a proposed capability were computed earlier.
11.23.17. WF-23.17 — Scoped Non-Bearer Capability
CR-2310 makes available the execution capability corresponding to the
validated Candidate Act.
The capability may bind:
(a) Candidate Act Descriptor digest;
(b) grant identity;
(c) authorized operation;
(d) source workload;
(e) destination;
(f) protected state version;
(g) validation-evidence digest;
(h) policy epoch;
(i) nonce;
(j) expiry;
(k) permitted usage; and
(l) designated Finality Sink.
Das Expires 19 April 2027 [Page 952]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative authenticated representation is:
Cact = Sign_skPED(Encode(hAct, hReceipt, GrantID, StateVersion,
Scope, Epoch, Nonce, Expiry, Sink))
The selected implementation may alternatively employ a MAC-
authenticated permit, protected capability table, sealed handle,
authenticated grant-state reference, or equivalent execution-
enablement mechanism.
The capability's non-bearer properties derive from enforcement of its
required operation, context, protected-state, usage, and sink
bindings.
Physical non-copyability is not universally required unless expressly
specified.
11.23.18. WF-23.18 — Current-State Finality Sink Verification
Before permitting the governed operation, FS-2312 verifies the actual
Candidate Act and required protected capability conditions.
The checks may include:
(a) capability authenticity;
(b) Candidate Act Descriptor correspondence;
(c) grant identity and scope;
(d) applicable current policy epoch;
(e) protected authorization-state version;
(f) nonce and expiry;
(g) capability reservation or usage state;
(h) validation-evidence commitment;
(i) destination or recipient;
(j) requesting workload identity;
(k) required revocation state; and
(l) Finality Sink identity.
Das Expires 19 April 2027 [Page 953]
Internet-Draft Protected AI Execution Finality October 2026
A capability that was valid when issued does not automatically remain
valid under incompatible current state when current verification is
mandatory.
The Finality Sink refuses operations whose required authorization
state no longer permits effectuation.
11.23.19. WF-23.19 — Finality Verification Predicate
An illustrative verification condition is:
PermitAct =
Auth(C) AND
Match(C,Dactual) AND
GrantValid(C,Gcurrent) AND
StateValid(C,Scurrent) AND
EvidenceValid(C,R) AND
SinkValid(C,F)
where:
C denotes the execution capability;
Dactual denotes the actual effectuation descriptor;
Gcurrent denotes applicable current protected grant state;
Scurrent denotes protected authorization and usage state;
R denotes required committed validation evidence; and
F denotes the designated Finality Sink.
The operation may cross the governed finality boundary only when all
mandatory predicates succeed.
An earlier ordinary application-level allow decision does not replace
the required capability and protected-state verification.
Das Expires 19 April 2027 [Page 954]
Internet-Draft Protected AI Execution Finality October 2026
11.23.20. WF-23.20 — Capability Consumption at Effectuation
Where the capability is single-use or usage-bounded, the protected
system consumes, invalidates, reserves, or advances the relevant
usage state before, or atomically with, permitted effectuation,
according to the selected embodiment.
A representative transition is:
USABLE → EFFECTUATION_RESERVED → CONSUMED.
The reservation or consumption mechanism prevents unauthorized
concurrent acceptance of the same restricted authorization.
For an interface controlled locally, the protected Finality Sink may
coordinate the state transition with admission of the operation.
For a remote external interface, the state transition may establish
local authority usage while external completion remains separately
recorded.
The architecture does not assume that local consumption can be
atomically committed with an arbitrary remote system's irreversible
operation.
11.23.21. WF-23.21 — Formal Candidate Act State Machine
OC-2313 maintains a bounded execution-finality state machine.
Non-limiting states include:
NON_FINAL;
DESCRIPTOR_PENDING;
DESCRIPTOR_FORMED;
VALIDATION_PENDING;
VALIDATION_FAILED;
HELD;
QUARANTINED;
ESCALATED;
CAPABILITY_PREPARED;
Das Expires 19 April 2027 [Page 955]
Internet-Draft Protected AI Execution Finality October 2026
CAPABILITY_RELEASED;
SINK_VERIFIED;
RELEASED;
DENIED;
REVOKED;
EXPIRED;
ZEROIZED.
For recovery purposes, the implementation may additionally
distinguish:
CONSUMPTION_RESERVED;
EFFECTUATION_ATTEMPTED;
CONFIRMED_EFFECTIVE;
INDETERMINATE.
The states are not presumed to have identical semantics.
In particular, CAPABILITY_RELEASED does not itself mean RELEASED or
CONFIRMED_EFFECTIVE.
A Candidate Act transitions to an externally effective state only
after satisfying the required Finality Sink verification and
effectuation conditions.
11.23.22. WF-23.22 — Protected Effectuation Outcome State
in the implementation described by enforcement point 31, OS-2314
maintains an operation-specific effectuation status.
The minimum stated categories comprise:
(a) pending;
(b) reserved for effectuation;
(c) confirmed effective;
(d) denied; and
Das Expires 19 April 2027 [Page 956]
Internet-Draft Protected AI Execution Finality October 2026
(e) indeterminate completion.
A representative state record comprises:
candidate_act_id;
operation_descriptor_digest;
grant_id;
capability_id;
effectuation_attempt_id;
finality_sink_id;
status;
reservation_reference;
consumption_reference;
protected_state_version;
last_verified_policy_epoch;
completion_evidence_reference.
Subsequent attempts are evaluated against the operation-specific
outcome and authorization state.
The effectuation record is not merely a historical diagnostic log
where its protected status is a mandatory predicate for preventing
unauthorized duplicate execution.
11.23.23. WF-23.23 — Distinction Between Reserved and Confirmed
Effective
A reserved operation has obtained or reserved protected authorization
for a possible effectuation attempt.
A confirmed-effective operation has sufficient evidence establishing
completion of the specified effect under the applicable Finality Sink
or receiving-system semantics.
The following inference is not assumed:
RESERVED implies CONFIRMED_EFFECTIVE.
Das Expires 19 April 2027 [Page 957]
Internet-Draft Protected AI Execution Finality October 2026
Likewise:
CAPABILITY_CONSUMED does not necessarily imply
REMOTE_OPERATION_COMPLETED.
For example, a protected network gateway may consume a single-use
capability and begin transmitting an authorized request.
If communication fails afterward, the gateway may be unable to
determine whether the receiving service committed its operation.
The protected outcome state therefore preserves the possibility of
indeterminate completion.
11.23.24. WF-23.24 — Anti-Replay Protection
in the implementation described by enforcement point 33, the scoped
execution capability is bound to:
(a) nonce;
(b) policy epoch;
(c) authorization-state version;
(d) operation descriptor; and
(e) Finality Sink identity.
The Finality Sink verifies those values against the current required
execution context immediately before effectuation.
The protected system consumes, invalidates, or advances capability-
usage state before, or atomically with, permitted effectuation.
A replayed capability is refused when its protected usage state no
longer permits the requested operation.
The anti-replay mechanism may use nonce verification, protected
counters, session binding, capability-consumption records, or
equivalent protected state.
No one mechanism is presumed mandatory across every implementation
unless the corresponding claim expressly requires it.
Das Expires 19 April 2027 [Page 958]
Internet-Draft Protected AI Execution Finality October 2026
11.23.25. WF-23.25 — Replay-Prevention Predicate
An illustrative anti-replay predicate is:
ReplayAcceptable =
NonceValid AND
EpochValid AND
StateVersionValid AND
UsageAvailable AND
OperationMatch AND
SinkMatch
where:
NonceValid verifies the required nonce or freshness condition;
EpochValid verifies the required policy epoch;
StateVersionValid verifies the protected authorization-state version;
UsageAvailable verifies remaining permitted capability use;
OperationMatch verifies the actual Candidate Act;
SinkMatch verifies the designated Finality Sink.
Where a capability is single-use, successful authorized consumption
changes the relevant protected usage state so that another
incompatible use fails.
Where a bounded multi-use capability is expressly authorized, the
applicable remaining-use or transfer-window conditions are enforced.
11.23.26. WF-23.26 — Cross-Destination and Cross-Sink Reuse Prevention
A valid capability may be presented in an unauthorized context.
Examples include:
(a) a different destination;
(b) another recipient;
Das Expires 19 April 2027 [Page 959]
Internet-Draft Protected AI Execution Finality October 2026
(c) a different transaction amount;
(d) a changed operation type;
(e) an incompatible workload identity;
(f) another protected authorization-state version; or
(g) a different Finality Sink.
The receiving Finality Sink verifies the actual operation against the
required capability bindings.
A capability permitting transmission to Service A does not
independently authorize transmission to Service B.
A capability intended for a network egress sink does not
independently authorize a receiving database commit.
Where the protected authorization permits bounded variation, the
Finality Sink applies the corresponding explicitly authorized scope
rather than assuming arbitrary substitutions are valid.
11.23.27. WF-23.27 — Retry Following Timeout
in the implementation described by enforcement point 24, a retry
following timeout is correlated with the original operation
identifier and protected authorization state.
A non-limiting retry request contains:
original_candidate_act_id;
retry_attempt_id;
original_descriptor_digest;
original_grant_reference;
capability_reference;
known_effectuation_status;
retry_reason;
current_policy_epoch.
RC-2315 consults the existing protected operation-state record.
Das Expires 19 April 2027 [Page 960]
Internet-Draft Protected AI Execution Finality October 2026
It determines whether the original attempt:
(a) never reached effectuation;
(b) was reserved but not admitted;
(c) was confirmed effective;
(d) was denied; or
(e) has an indeterminate outcome.
A timeout alone does not prove that no external effect occurred.
The system therefore does not automatically issue a new independently
reusable authorization solely because the requesting agent did not
receive a response.
11.23.28. WF-23.28 — Protected Recovery Predicate
Where an earlier operation has an indeterminate completion status,
the protected system evaluates whether a further attempt can be
authorized without causing an unauthorized duplicate effect.
An illustrative recovery predicate is:
Vrecovery =
SameCandidateAct AND
CurrentAuthorityValid AND
ProtectedStateConsistent AND
DuplicateEffectExcluded AND
RecoveryScopeValid
where:
SameCandidateAct verifies correlation to the original consequential
operation;
CurrentAuthorityValid verifies applicable current protected
authority;
ProtectedStateConsistent verifies protected reservation, consumption,
and outcome state;
Das Expires 19 April 2027 [Page 961]
Internet-Draft Protected AI Execution Finality October 2026
DuplicateEffectExcluded establishes the duplicate-effect prevention
condition required by the selected recovery mechanism; and
RecoveryScopeValid verifies that the proposed recovery procedure is
authorized.
Where the system cannot establish a mandatory duplicate-exclusion
predicate, the independently reusable authorization is withheld.
A recovery process may report an unresolved outcome rather than
claiming successful prevention or completion.
11.23.29. WF-23.29 — Recovery After Failure Before Protected Commitment
Consider a failure before the required protected finality transaction
commits.
The proposed Candidate Act may have passed some preliminary
authorization checks.
However, the protected state, required validation evidence, or
capability availability has not successfully committed.
The system does not treat the incomplete process as an authorized
effectuation.
On recovery, the PED obtains the current required authority and
protected state.
The Candidate Act may be revalidated.
A new valid capability may become available only after all applicable
mandatory commitment conditions succeed.
The previous incomplete attempt does not confer unrestricted
authority.
11.23.30. WF-23.30 — Recovery After Commitment but Before Capability
Delivery
A protected finality transaction may complete, but communication to
the requesting execution environment may fail before delivery of the
capability.
The recovery component consults the committed transaction record.
It determines whether the corresponding capability:
Das Expires 19 April 2027 [Page 962]
Internet-Draft Protected AI Execution Finality October 2026
(a) was successfully created or activated;
(b) remains within its validity scope;
(c) has already been consumed;
(d) is reserved for an attempted effect;
(e) has expired or been revoked; or
(f) requires protected retirement.
Where the original capability remains valid and unused under its
required conditions, the protected system may recover or make
available that same authorization according to the selected design.
It does not automatically mint a second independent grant for the
same restricted operation.
11.23.31. WF-23.31 — Recovery After Capability Delivery but Before
Effectuation
A requesting agent may receive or reference a valid capability and
fail before presenting it to the Finality Sink.
On recovery, the system determines whether the capability remains
valid under:
(a) the original Candidate Act Descriptor;
(b) current required policy state;
(c) protected nonce or usage state;
(d) expiry;
(e) revocation;
(f) workload context; and
(g) the designated Finality Sink.
Where the original capability remains valid and the protected usage
state permits its use, the applicable recovery procedure may permit
continuation.
Where the mandatory authorization context has changed incompatibly,
renewed protected validation is required.
Das Expires 19 April 2027 [Page 963]
Internet-Draft Protected AI Execution Finality October 2026
The capability's earlier availability does not override current
required Finality Sink checks.
11.23.32. WF-23.32 — Recovery After Effectuation Attempt
An operation may be admitted at the Finality Sink and then encounter
a failure before its completion outcome is known.
For example, an agent may send an authorized payment request through
a protected gateway.
The gateway verifies and consumes the capability.
The remote payment service may process the operation.
The connection may then fail before an acknowledgment reaches the
gateway.
The protected outcome state records the attempted operation and its
indeterminate completion where appropriate.
The recovery controller does not treat the lack of acknowledgment as
proof of failure.
A new consequential attempt remains subject to the duplicate-effect
prevention and recovery predicates.
11.23.33. WF-23.33 — Receiving-Side Reconciliation
Where supported, RR-2319 obtains authenticated receiving-side
operation status.
The receiving system may provide:
(a) operation identifier;
(b) idempotency-key status;
(c) transaction reference;
(d) commit sequence;
(e) authenticated completion record;
(f) durable receiving-side outcome; or
(g) another reliable status artifact.
Das Expires 19 April 2027 [Page 964]
Internet-Draft Protected AI Execution Finality October 2026
The recovery component verifies the correspondence between the
receiving-side record and the original Candidate Act.
If completion is established, the protected operation state is
updated accordingly.
If non-completion is reliably established, a protected recovery
predicate may permit an authorized retry.
If the outcome remains indeterminate, the system does not
independently assume retry safety.
11.23.34. WF-23.34 — Idempotency and Duplicate-Effect Protection
An external system may support a durable idempotency mechanism.
In that case, the protected workflow may associate the Candidate Act
with a stable idempotency identifier.
A non-limiting record comprises:
candidate_act_id;
idempotency_key;
destination_service;
operation_digest;
authorization_reference;
receiving_status;
protected_completion_reference.
The key identifies the same logical operation across permitted
retries.
However, an idempotency key alone does not guarantee duplicate-effect
prevention unless the receiving system actually implements the
necessary durable idempotency semantics.
Where the receiving system lacks such support, the protected system
must use another supported duplicate-exclusion mechanism or withhold
a retry whose safety cannot be established.
Das Expires 19 April 2027 [Page 965]
Internet-Draft Protected AI Execution Finality October 2026
11.23.35. WF-23.35 — Protected Retry Authority
Where recovery itself requires execution authority, the retry
procedure may be represented as a governed recovery operation.
The protected authority evaluates:
(a) original Candidate Act identity;
(b) previous effectuation status;
(c) current Authority Object;
(d) protected grant-consumption state;
(e) receiving-side status where available;
(f) applicable policy epoch;
(g) destination and operation correspondence; and
(h) the required duplicate-effect prevention condition.
An authorized recovery instruction does not automatically constitute
permission to produce a second independently effective operation.
The recovery mechanism must preserve the applicable original
operation identity and protected finality restrictions.
11.23.36. WF-23.36 — Revocation During an Interrupted Operation
Revocation may occur while a Candidate Act is:
(a) pending;
(b) validating;
(c) capability-prepared;
(d) capability-released;
(e) reserved for effectuation; or
(f) awaiting outcome confirmation.
RV-2317 advances or records the relevant protected revocation state.
Das Expires 19 April 2027 [Page 966]
Internet-Draft Protected AI Execution Finality October 2026
The Finality Sink verifies the required current revocation predicate
before admitting a still-pending governed effect.
Where an earlier effect has already occurred, revocation does not
retroactively prevent it.
Where a remote effect remains indeterminate, the recovery process
preserves that uncertainty rather than assuming the revocation
cancelled the prior request.
11.23.37. WF-23.37 — Snapshot and State-Rollback Protection
An AI workload may be restarted from an earlier snapshot.
The snapshot may contain:
(a) a copy of a capability;
(b) an earlier nonce;
(c) cached policy state;
(d) an operation request;
(e) an earlier pending-state record; or
(f) an application-level indication that the operation was not
completed.
The authoritative protected grant and capability-consumption state
remains outside the rollback-accessible workload domain where
rollback protection is required.
Following restoration, the Finality Sink consults current protected
state.
A previously consumed or revoked single-use capability is not
restored merely because the workload snapshot contains an earlier
copy.
The strength of the rollback guarantee depends upon the actual
protection of the authoritative state mechanism.
11.23.38. WF-23.38 — Distributed Protected-State Consistency
The PED, capability issuer, and Finality Sink may operate on separate
authenticated nodes.
Das Expires 19 April 2027 [Page 967]
Internet-Draft Protected AI Execution Finality October 2026
The system preserves the required correspondence among:
(a) Candidate Act identity;
(b) grant identity;
(c) authorization-state version;
(d) validation-evidence commitment;
(e) capability identifier;
(f) Finality Sink identity;
(g) nonce and usage state; and
(h) effectuation outcome.
A distributed implementation may use authenticated state replication,
protected serialization, durable reservation records, consensus-
backed state, or another suitable mechanism.
No particular distributed database or consensus protocol is mandatory
unless required by the selected embodiment.
Where the current state cannot be established with the required
consistency, the affected operation remains blocked.
A design that permits incompatible copies of the same single-use
grant to be consumed independently would not provide the required
duplicate-consumption guarantee.
11.23.39. WF-23.39 — Atomicity and Remote-Effect Limitation
The architecture distinguishes local protected atomicity from
globally atomic external effectuation.
An Atomic Protected-State Transition can ensure that the
authorization grant and associated protected records change
consistently.
An Atomic Finality Commit can ensure that mandatory authorization-
state and evidence conditions are committed together before
capability usability.
However, a remote payment processor, messaging service, network
recipient, or physical system may not participate in that protected
transaction.
Das Expires 19 April 2027 [Page 968]
Internet-Draft Protected AI Execution Finality October 2026
Therefore, the system does not automatically guarantee:
(a) exactly-once delivery;
(b) exactly-once remote execution;
(c) instantaneous rollback of external effects; or
(d) globally atomic commitment across unrelated receiving systems.
Stronger guarantees require an appropriate controlled receiving-side
boundary, transaction protocol, durable idempotency mechanism, or
other verified coordination procedure.
11.23.40. WF-23.40 — Illustrative Atomic Grant Consumption
An AI agent proposes a consequential API operation.
The applicable protected grant permits one execution.
The grant-state record indicates:
grant_id = G1;
remaining_uses = 1;
status = ACTIVE.
Two concurrent agent requests attempt to execute the operation using
the same grant.
The Protected Enforcement Domain serializes or atomically coordinates
the required state transition.
The first authorized operation obtains the permitted grant
reservation.
The protected remaining-use state advances.
The competing request cannot obtain a second independently valid
authorization from the same restricted grant.
The required validation evidence is committed and the authorized
capability becomes usable according to the protected finality
transaction.
The Finality Sink verifies the permitted operation and current usage
state before effectuation.
Das Expires 19 April 2027 [Page 969]
Internet-Draft Protected AI Execution Finality October 2026
11.23.41. WF-23.41 — Illustrative Crash Before Capability Release
An agent prepares an external network request.
The PED validates the operation.
Before the required evidence and protected-state transaction
completes, the authorization component crashes.
On restart, the recovery controller consults the authoritative
protected state.
The incomplete mandatory transaction is not treated as successful.
The proposed request remains non-effective.
The system may perform renewed protected validation under the current
authority conditions.
No valid execution capability is presumed to exist merely because
preliminary validation had succeeded.
11.23.42. WF-23.42 — Illustrative Timeout After Credential-Mediated
Effectuation
An AI agent proposes a transaction requiring a protected API
credential.
The privileged connector verifies the required authorization
commitment and capability.
The credential is applied to the validated request.
The request reaches the external service, but the response is lost.
The protected operation state records that effectuation was attempted
and that remote completion is uncertain.
The agent issues a retry request.
The recovery controller correlates it with the original Candidate
Act.
It does not automatically issue a new independently reusable
authorization.
Das Expires 19 April 2027 [Page 970]
Internet-Draft Protected AI Execution Finality October 2026
Where a reliable receiving-side idempotency or status mechanism
establishes the necessary duplicate-prevention condition, a bounded
recovery procedure may be permitted.
Otherwise, the operation remains indeterminate pending further
authorized reconciliation.
11.23.43. WF-23.43 — Illustrative Snapshot Replay
An AI workload receives a single-use capability authorizing a
protected storage operation.
The storage Finality Sink verifies the capability and consumes the
corresponding protected usage state.
An earlier VM snapshot is restored.
The restored workload contains an older copy of the capability.
The workload attempts the same storage operation again.
The Finality Sink checks the authoritative protected consumption
state.
The capability is already consumed.
The repeated operation is refused.
The snapshot cannot re-create the previously consumed execution
authority.
11.23.44. WF-23.44 — Illustrative Cross-Sink Capability Reuse
An agent receives a capability permitting one network transmission.
The corresponding network Finality Sink successfully verifies the
capability.
The agent attempts to reuse the same capability at a storage-commit
interface.
The storage Finality Sink verifies the actual operation and
designated sink identity.
The capability does not authorize the storage-commit boundary.
The operation is refused.
Das Expires 19 April 2027 [Page 971]
Internet-Draft Protected AI Execution Finality October 2026
This illustrates that a previously valid capability cannot be reused
outside its authorized effectuation boundary merely because its
cryptographic authentication is valid.
11.23.45. WF-23.45 — Alternative Technical Implementations
Single-node protected transaction: Protected validation, state
handling, evidence commitment, and capability activation occur within
one protected controller or transactional store.
HSM-assisted implementation: A protected cryptographic component
controls capability issuance and relevant state transitions.
Protected database implementation: A transactionally consistent
authorization-state store maintains grants, nonces, reservations, and
consumption.
Hardware-counter implementation: A trusted monotonic counter or
protected sequence supports replay prevention.
Credential-broker implementation: A privileged connector verifies the
protected grant and exact operation before applying credentials.
Network Finality Sink implementation: A protected egress controller
verifies the capability and usage state before transmission.
Storage Finality Sink implementation: A controlled commit interface
verifies operation-specific authority before persistent mutation.
Receiving-side idempotency implementation: The receiving service
maintains durable operation identifiers or commit results supporting
safe retry.
Distributed protected-state implementation: Authenticated authority
and Finality Sink nodes maintain the consistency required for bounded
capability use.
Confidential-computing implementation: Protected state remains
authoritative outside rollback-accessible workload snapshots.
The choice of implementation does not remove mandatory authorization,
evidence, consumption, and actual effectuation verification
requirements.
Das Expires 19 April 2027 [Page 972]
Internet-Draft Protected AI Execution Finality October 2026
11.23.46. WF-23.46 — Failure and Fail-Closed Conditions
The system refuses, withholds, or retains a Candidate Act in a Non-
Effective State when a mandatory condition is absent, invalid,
inconsistent, expired, revoked, replayed, or unverifiable.
Non-limiting failure conditions include:
(a) missing active grant;
(b) unauthorized operation scope;
(c) invalid grant authenticity;
(d) expired grant;
(e) revoked grant;
(f) exhausted permitted usage count;
(g) concurrent unauthorized grant consumption;
(h) nonce replay;
(i) incompatible policy epoch;
(j) invalid authorization-state version;
(k) failed atomic state transition;
(l) incomplete required finality commit;
(m) failed validation-evidence commitment;
(n) missing execution capability;
(o) invalid capability authentication;
(p) Candidate Act Descriptor mismatch;
(q) destination substitution;
(r) Finality Sink mismatch;
(s) consumed capability;
(t) unauthorized retry;
Das Expires 19 April 2027 [Page 973]
Internet-Draft Protected AI Execution Finality October 2026
(u) indeterminate prior effectuation without a satisfied recovery
predicate;
(v) inconsistent protected recovery state;
(w) rollback of required authoritative state;
(x) unavailable mandatory current revocation information; or
(y) failure of required Finality Sink verification.
Failure of a transaction, timeout, or process restart does not
independently grant execution authority.
11.23.47. WF-23.47 — PHOSITA Verification and Negative Tests
A person having ordinary skill in distributed systems, transactional
state management, cryptography, AI-agent security, protected
execution, and external service integration may verify the
architecture through the following tests.
Test 1 — Valid atomic grant consumption: Authorize one operation
under a single-use protected grant and confirm that the corresponding
state transition succeeds.
Test 2 — Concurrent duplicate attempts: Submit two competing
operations against one single-use grant. Only the permitted number
of grants may be consumed.
Test 3 — Failed state transition: Interrupt the required protected-
state transaction. No independently usable capability becomes
available.
Test 4 — Failed evidence commitment: Interrupt mandatory validation-
evidence commitment. The corresponding capability remains unusable.
Test 5 — Capability prepared but not released: Prepare a capability
before completing required protected commitment. The Finality Sink
refuses effectuation.
Test 6 — Valid Finality Sink verification: Present a matching
capability and current state. The corresponding operation is
permitted.
Test 7 — Missing capability: Present the operation without the
required execution capability. Effectuation is refused.
Das Expires 19 April 2027 [Page 974]
Internet-Draft Protected AI Execution Finality October 2026
Test 8 — Consumed capability: Reuse a consumed single-use capability.
Protected usage verification rejects the attempt.
Test 9 — Nonce replay: Present a previously invalidated nonce.
Required freshness verification fails.
Test 10 — Policy-epoch mismatch: Present a capability under
incompatible current protected policy state. Effectuation is denied.
Test 11 — Wrong destination: Change the recipient or destination
after authorization. Required descriptor correspondence fails.
Test 12 — Wrong Finality Sink: Present a capability at an
unauthorized effectuation interface. Sink binding fails.
Test 13 — Concurrent capability consumption: Submit simultaneous
attempts at one restricted sink. Protected state prevents
unauthorized double consumption.
Test 14 — Crash before commit: Interrupt the PED before finality
commitment. The pending operation remains non-effective.
Test 15 — Crash after commit: Interrupt capability delivery after
protected commitment. Recovery consults existing state rather than
minting a duplicate independent grant.
Test 16 — Crash before sink admission: Restart the requester before
effectuation. Required current capability verification remains
mandatory.
Test 17 — Timeout after remote submission: Lose the remote
acknowledgment after possible effectuation. The outcome is preserved
as indeterminate.
Test 18 — Unauthorized retry: Attempt another consequential operation
without satisfying the protected recovery predicate. The retry is
refused.
Test 19 — Receiving-side idempotency: Use a receiving service with
verified durable idempotency and evaluate an authorized bounded
retry.
Test 20 — No receiving-side idempotency: Simulate an uncertain
operation against a non-idempotent service. No unsupported exactly-
once guarantee is asserted.
Das Expires 19 April 2027 [Page 975]
Internet-Draft Protected AI Execution Finality October 2026
Test 21 — Snapshot rollback: Restore an earlier workload image
containing a consumed capability. Current protected state rejects
reuse.
Test 22 — Protected-state rollback: Attempt to restore an older
authoritative grant-state record. Required rollback protection
rejects or detects the incompatible state.
Test 23 — Revocation before effectuation: Revoke the applicable
authority before the Finality Sink admits the operation. Required
current-state verification refuses it.
Test 24 — Revocation after completed effect: Revoke authority after
the operation has completed. The completed effect is not falsely
classified as prevented.
Test 25 — Bounded multi-use capability: Permit an expressly
authorized number of uses and refuse operations exceeding the
protected usage allowance.
Test 26 — Distributed state inconsistency: Present incompatible grant
or capability state across protected nodes. The system refuses an
operation whose mandatory consistency cannot be established.
Test 27 — Candidate Act versus attempt identity: Submit retries with
different attempt identifiers but the same logical Candidate Act and
verify protected correlation.
Test 28 — Different Candidate Act: Attempt to reuse authorization for
another concrete operation. Descriptor and scope verification reject
it.
Test 29 — Credential-mediated recovery: Retry an uncertain protected
credential operation and enforce the original operation's recovery
restrictions.
Test 30 — Receiving-side completion evidence: Obtain an authenticated
completion record and reconcile the protected outcome.
Test 31 — Partial effectuation: Interrupt a multi-unit operation and
preserve the distinction between completed, pending, and uncertain
units.
Test 32 — Single-node finality: Implement protected transaction and
Finality Sink functions in one protected node and verify required
ordering.
Das Expires 19 April 2027 [Page 976]
Internet-Draft Protected AI Execution Finality October 2026
Test 33 — Distributed finality: Implement the PED and Finality Sink
on different nodes and verify authenticated state and capability
correspondence.
Test 34 — Replay across sessions: Attempt capability reuse under an
incompatible session or workload context. Mandatory context
verification fails.
Test 35 — Recovery-only operation: Attempt a consequential rollback
or compensation action without its separately required authority.
The action is refused.
Tests may employ transaction fault injection, controlled process
termination, simulated network partitions, snapshot restoration,
protected counters, duplicate request generators, mock payment or API
services, and authenticated operation-status interfaces.
The tests demonstrate only the properties actually enforced by the
implementation and the receiving systems used.
11.23.48. WF-23.48 — Claim-Specific Technical Support
Enforcement Point 20 — Protected Grant-State Consumption
WF-23.9 through WF-23.14 describe the protected grant-state record,
active grant, authorized operation, validity interval, permitted
usage count, revocation state, atomic consumption, and prevention of
unauthorized duplicate effects arising from grant reuse.
Enforcement Point 24 — Crash, Retry and Duplicate-Effect Protection
WF-23.21 through WF-23.35 describe the protected operation-state
machine, pending and authorized states, consumption reservations,
terminal outcomes, original operation identifiers, retry correlation,
indeterminate completion, and protected recovery predicates.
Enforcement Point 31 — Protected Effectuation Outcome State
WF-23.22, WF-23.23, WF-23.32 and WF-23.33 describe protected pending,
reserved, confirmed-effective, denied, and indeterminate states used
to evaluate subsequent execution attempts and prevent unauthorized
duplicate external effects.
Enforcement Point 33 — State-Bound Finality and Replay Protection
Das Expires 19 April 2027 [Page 977]
Internet-Draft Protected AI Execution Finality October 2026
WF-23.17 through WF-23.26 describe cryptographic binding to nonce,
policy epoch, authorization-state version, operation descriptor, and
Finality Sink identity; verification against current state
immediately before effectuation; protected usage consumption; and
refusal of replay, destination substitution, or cross-sink reuse.
Related parent-claim requirements
enforcement point 20 and 24 operate through the protected sandbox-
egress grant-state architecture associated with enforcement point 19
and 20.
enforcement point 31 depends upon the transaction-bound credential-
effectuation architecture of enforcement point 28.
enforcement point 33 depends upon the protected agent-egress finality
method of enforcement point 32.
The workflow is therefore a cross-cutting implementation narrative,
not a replacement for those distinct parent-claim limitations.
11.23.49. WF-23.49 — Technical Effect
The workflow establishes a protected causal sequence between:
(a) generation of a consequential Candidate Act;
(b) interception and Non-Effective State holding;
(c) construction of an effectuation-relevant descriptor;
(d) verification of protected grant authority;
(e) atomic or appropriately consistent reservation and consumption of
required state;
(f) protected authorization-state advancement;
(g) required validation-evidence commitment;
(h) scoped execution-capability availability;
(i) independent Finality Sink verification;
(j) bounded effectuation;
(k) protected capability consumption;
Das Expires 19 April 2027 [Page 978]
Internet-Draft Protected AI Execution Finality October 2026
(l) recording of effectuation status;
(m) controlled recovery following failure; and
(n) prevention of unauthorized duplicate effects.
The Atomic Protected-State Transition prevents incomplete or
inconsistent grant-state handling from creating unauthorized
authority.
The protected validation-evidence commitment establishes the required
pre-effectuation authorization dependency where mandated.
The scoped capability prevents authorization from being reused
outside its permitted act, state, and Finality Sink conditions.
The recovery mechanism distinguishes a failed authorization attempt
from an operation that may already have become externally effective.
The effectuation-outcome store preserves confirmed, pending, and
indeterminate statuses instead of assuming that every timeout means
failure.
The architecture provides duplicate-effect prevention to the extent
enforced by protected capability state and the applicable receiving-
side mechanisms, without claiming unconditional globally exactly-once
completion.
Computation is not authority to act.
Validation is not effectuation.
Reservation is not confirmation of completion.
A previously valid capability is not automatically valid for reuse.
A timeout is not proof that an external operation failed.
Recovery does not independently confer authority to execute again.
Protected atomicity must preserve the required authorization
dependencies before consequential effectuation.
11.24. WF-24 — Multiple Finality Sinks, Independent Downstream
Verification, Multi-Boundary Candidate Act Classification,
Receiving-Side Finality, and Protected Cross-Boundary Execution
Authority
Das Expires 19 April 2027 [Page 979]
Internet-Draft Protected AI Execution Finality October 2026
11.24.1. WF-24.1 — Technical Purpose
This embodiment describes a computer-implemented protected execution-
finality architecture for governing workflows in which an artificial-
intelligence agent, autonomous service, or distributed computation
generates multiple consequential operations that may become effective
at different technical boundaries.
The system distinguishes authorization of computation, admission of
agent delegation, preparation of a consequential operation, protected
authorization of that operation, and actual effectuation at its
designated Finality Sink.
A successful authorization at one boundary does not automatically
confer authority to complete a different consequential operation at
another boundary.
The architecture provides:
(a) classification of consequential operations according to their
effectuation boundaries;
(b) formation of a separate Candidate Act Descriptor for each
governed operation;
(c) protected validation against the applicable Authority Object and
current authorization state;
(d) protected evidence commitment where required;
(e) issuance or availability of operation-scoped execution
capabilities;
(f) independent verification at the designated Finality Sink;
(g) receiving-side verification of the actual operation;
(h) protection against unauthorized propagation or reuse of execution
authority;
(i) enforcement of distinct authorization conditions across multi-
agent workflows;
(j) control of streaming outputs and buffered consequential
operations; and
(k) consistent recovery and revocation across multiple enforcement
boundaries.
Das Expires 19 April 2027 [Page 980]
Internet-Draft Protected AI Execution Finality October 2026
A model-access decision may permit computation.
A Delegation Capability may permit a subordinate agent to accept a
bounded delegated task.
A network capability may permit transmission.
A storage capability may permit a specified persistent mutation.
A payment capability may permit a particular financial operation.
These permissions control different technical events.
The architecture does not treat any one of them as universal
authority to perform all remaining steps in the workflow.
The central rule is:
A consequential operation becomes effective only after the Finality
Sink governing that operation verifies its applicable protected
execution authority.
11.24.2. WF-24.2 — Participating Technical Components
In one non-limiting implementation, the system comprises the
following components.
AE-2401 — Primary AI Execution Environment
An autonomous agent, model runtime, orchestration service, or other
computing component configured to perform computations and prepare
consequential operations.
MC-2402 — Model-Computation Admission Component
A protected or enforcement-controlled component governing admission
of the agent's model-computation requests.
AR-2403 — Protected Computation-Admission Record
An authenticated record representing the permitted model, workload,
approved execution context, policy epoch, and authorization-state
reference.
DA-2404 — Delegation Authorization Component
A protected component configured to validate proposed delegation to a
subordinate agent under the applicable Delegation Authority Object.
Das Expires 19 April 2027 [Page 981]
Internet-Draft Protected AI Execution Finality October 2026
SA-2405 — Subordinate Agent Execution Environment
A child agent, delegated tool agent, sub-agent, or other subordinate
computation process operating under bounded delegated authority.
OC-2406 — Consequential Operation Classification Component
A component configured to identify consequential operations and
determine their respective effectuation classes.
FC-2407 — Finality Sink Classification Component
A mechanism configured to map each governed consequential operation
to its applicable Finality Sink.
HQ-2408 — Non-Effective Candidate Act Holding Mechanism
An enforcement-controlled buffer, queue, pending request record,
inactive command, or equivalent mechanism maintaining consequential
operations before authorization.
DC-2409 — Candidate Act Descriptor Component
A mechanism configured to construct or verify operation-specific
descriptors.
PED-2410 — Protected Enforcement Domain
A protected authorization component configured to validate each
Candidate Act against its applicable Authority Object, execution
context, protected policy state, and required Finality Sink.
AS-2411 — Protected Authority Store
An authenticated source of operation, delegation, workload,
destination, purpose, scope, and effectuation authorization
conditions.
PS-2412 — Protected Authorization-State Store
A mechanism maintaining protected grants, policy epochs, revocation
state, nonces, usage limits, capability consumption, and validation-
state commitments.
EV-2413 — Protected Validation-Evidence Component
A mechanism configured to generate or commit an authenticated
operation-specific validation record.
Das Expires 19 April 2027 [Page 982]
Internet-Draft Protected AI Execution Finality October 2026
CR-2414 — Scoped Execution-Capability Component
A protected component configured to generate, register, derive,
release, or activate operation-specific capabilities.
FS-2415 — Network Effectuation Finality Sink
A controlled network gateway, egress proxy, NIC, SmartNIC, DPU, or
equivalent interface governing transmission.
FS-2416 — Tool and API Finality Sink
A controlled tool executor, API gateway, protected connector, or
equivalent interface governing consequential service invocation.
FS-2417 — Credential-Use Finality Sink
A protected credential broker or cryptographic key-use interface
governing consequential credential application.
FS-2418 — Persistent-State Finality Sink
A protected file-modification controller, database-commit interface,
storage controller, or equivalent persistent effectuation boundary.
FS-2419 — Financial or Transaction Finality Sink
A protected payment, transaction, settlement, or financial execution
interface.
FS-2420 — Hardware or Physical Finality Sink
A hardware-assisted actuator, accelerator-output interface, fabric
controller, deployment controller, or other governed consequential
interface.
RV-2421 — Receiving-Side Actual-Operation Verifier
A component configured to obtain, reconstruct, or verify an operation
at a remote or downstream receiving-side boundary.
SC-2422 — Cross-Boundary Authorization-Consistency Component
A mechanism configured to preserve the required relationships among
operation identities, capabilities, state versions, validation
records, and designated Finality Sinks.
OS-2423 — Protected Effectuation-Outcome Store
Das Expires 19 April 2027 [Page 983]
Internet-Draft Protected AI Execution Finality October 2026
A mechanism maintaining pending, reserved, authorized, denied,
confirmed-effective, revoked, and indeterminate operation states.
RC-2424 — Protected Recovery and Reconciliation Component
A mechanism coordinating authorized recovery from interrupted or
uncertain multi-boundary operations.
The components may operate within one protected node or across
separately authenticated systems.
Multiple Finality Sinks may share a PED while retaining separate
operation-specific effectuation authority.
11.24.3. WF-24.3 — Distinction Between Computation and Effectuation
The primary AI agent may:
(a) execute model inference;
(b) analyze information;
(c) generate task plans;
(d) call permitted computational tools;
(e) construct a service request;
(f) prepare a transaction;
(g) select a destination;
(h) generate a file modification; or
(i) produce another operation proposal.
These activities do not automatically confer authority to complete
all consequential effects represented by the computational output.
The system distinguishes computation-admission authority from
operation-specific effectuation authority.
An approved computation may generate an unauthorized Candidate Act.
Conversely, the system may refuse additional model computation while
retaining an already generated Candidate Act in a Non-Effective State
pending separately required finality verification.
Das Expires 19 April 2027 [Page 984]
Internet-Draft Protected AI Execution Finality October 2026
11.24.4. WF-24.4 — Identification of Distinct Effectuation Classes
OC-2406 identifies whether a proposed operation creates a governed
effect at one or more boundaries.
Illustrative classes include:
(a) model-computation admission;
(b) delegation admission;
(c) tool execution;
(d) external network transmission;
(e) protected credential application;
(f) persistent file mutation;
(g) database commitment;
(h) message delivery;
(i) payment execution;
(j) artifact publication;
(k) software deployment;
(l) accelerator-state export; and
(m) device actuation.
The classification depends upon the actual consequence being
controlled.
A prepared data structure is not necessarily an externally effective
operation.
A database commit or external transmission may be consequential even
if generated as a small part of a larger authorized agent workflow.
11.24.5. WF-24.5 — Effectuation Boundary Registry
FC-2407 maintains or resolves an authenticated registry of the
Finality Sink governing each consequential operation class.
A non-limiting mapping record comprises:
Das Expires 19 April 2027 [Page 985]
Internet-Draft Protected AI Execution Finality October 2026
operation_class;
effectuation_boundary_id;
finality_sink_identity;
authorized_execution_scope;
descriptor_schema_reference;
required_authority_object;
required_protected_state;
capability_verification_method;
applicable_policy_epoch.
The registry may be protected within the PED, maintained by an
authenticated infrastructure controller, or represented through
authorized policy configuration.
The requesting AI agent cannot unilaterally select a weaker Finality
Sink when the applicable operation requires a stronger protected
effectuation boundary.
11.24.6. WF-24.6 — Classification of a Multi-Operation Workflow
An agentic workflow may produce several consequential operations.
For example:
Operation 1 — external information retrieval.
Operation 2 — protected credential use.
Operation 3 — modification of a database record.
Operation 4 — payment execution.
Operation 5 — delivery of an external notification.
FC-2407 associates each operation with the appropriate Finality Sink.
The classification may be represented as:
CA_1 → FS_network
Das Expires 19 April 2027 [Page 986]
Internet-Draft Protected AI Execution Finality October 2026
CA_2 → FS_credential
CA_3 → FS_database
CA_4 → FS_payment
CA_5 → FS_message
These associations represent effectuation authority, not merely a
preferred routing arrangement.
A capability for CA_1 does not independently authorize CA_3 or CA_4.
11.24.7. WF-24.7 — Separation of Delegation from Downstream
Effectuation
in the implementation described by enforcement point 42, the primary
agent may propose delegation of a task to SA-2405.
The proposed delegation is represented as a Candidate Delegation Act.
DA-2404 validates the proposed delegation under the applicable
Delegation Authority Object.
The protected delegation authorization may consider:
(a) permitted subtask class;
(b) tool class;
(c) data scope;
(d) memory scope;
(e) time window;
(f) recursion limit;
(g) execution budget;
(h) prohibited operation class;
(i) policy epoch;
(j) revocation state; and
(k) nonce conditions.
Das Expires 19 April 2027 [Page 987]
Internet-Draft Protected AI Execution Finality October 2026
Successful validation may permit acceptance of the bounded
delegation.
However, it does not independently authorize a later externally
effective tool invocation, file mutation, network transmission,
credential release, payment, or other consequential operation.
Each governed downstream operation remains subject to its applicable
protected execution-finality validation and Finality Sink
verification.
11.24.8. WF-24.8 — Delegation Acceptance Boundary
A proposed delegation may be held as a Candidate Delegation Act.
A delegation-acceptance Finality Sink verifies the required
Delegation Capability before the subordinate agent receives
executable delegated authority.
The Delegation Capability may identify the permitted objective, data
scope, tool permissions, recursion limits, execution budget, and
validity conditions.
The subordinate agent operates within that bounded scope.
Delegation acceptance establishes the permitted subordinate
computational or task authority.
It does not eliminate downstream operation-specific finality
requirements.
The delegation-acceptance boundary and later consequential
effectuation boundaries perform distinct functions.
11.24.9. WF-24.9 — Subordinate-Agent Candidate Act
SA-2405 may generate a proposed consequential operation.
For example, a delegated research agent may prepare an authorized
database update or outbound API request.
The operation is independently classified as a Candidate Act.
The protected authorization may validate:
(a) the subordinate workload identity;
(b) permitted delegation scope;
Das Expires 19 April 2027 [Page 988]
Internet-Draft Protected AI Execution Finality October 2026
(c) the actual operation;
(d) destination;
(e) purpose;
(f) remaining usage allowance;
(g) policy epoch;
(h) revocation state; and
(i) designated Finality Sink.
A valid Delegation Capability may contribute required authority
context.
It does not automatically substitute for the downstream operation-
specific execution capability.
11.24.10. WF-24.10 — Separation of Model Admission from Downstream
Effectuation
In the embodiments corresponding to enforcement point 57, 68 and 95,
MC-2402 controls admission of a proposed inference or agent-
computation request.
The protected computation-admission procedure may validate:
(a) workload identity;
(b) requested model;
(c) approved computation context;
(d) execution purpose;
(e) policy state; and
(f) applicable admission authorization.
Successful admission permits the approved computation.
It does not independently authorize externally effective operations
generated by that computation.
A resulting tool call, network transmission, file mutation, or other
consequential operation is classified as a separate Candidate Act.
Das Expires 19 April 2027 [Page 989]
Internet-Draft Protected AI Execution Finality October 2026
The downstream operation remains subject to its own protected
validation, scoped execution-capability release, and applicable
Finality Sink verification.
11.24.11. WF-24.11 — Inference-to-Act Context Binding
in the implementation described by enforcement point 69, the
protected computation-admission record may identify:
(a) model identity;
(b) workload identity;
(c) approved execution context;
(d) policy epoch; and
(e) authorization-state identifier.
The operation-specific authorization context may reference or
cryptographically bind the computation-admission record to the
downstream Candidate Act Descriptor.
A non-limiting association is:
Bcontext = H(Encode(AdmissionRecordDigest, CandidateActDigest,
WorkloadID, ContextVersion))
where the corresponding fields identify the computation-admission
evidence and consequential operation.
The association may support authentication of the operation's
admitted computation context.
However, the computation-admission record is not treated as
sufficient execution authority.
The downstream capability remains separately required.
11.24.12. WF-24.12 — Candidate Act Generation and Holding
The agent or subordinate execution environment generates a proposed
consequential operation.
The operation is classified as Candidate Act CA_i.
HQ-2408 maintains CA_i in a Non-Effective State.
Das Expires 19 April 2027 [Page 990]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative record comprises:
candidate_act_id;
source_agent_id;
source_computation_reference;
delegation_reference;
operation_class;
target_resource;
destination_reference;
payload_reference;
required_finality_sink;
status = NON_EFFECTIVE.
The proposed operation remains blocked while the applicable protected
authorization conditions are unresolved.
The existence of an earlier computation-admission or delegation
authorization does not independently release CA_i.
11.24.13. WF-24.13 — Operation-Specific Descriptor Formation
DC-2409 constructs an operation-specific Candidate Act Descriptor.
A representative descriptor comprises:
candidate_act_id;
source_agent_identity;
source_workload_identity;
operation_class;
destination_or_recipient;
target_resource;
operation_parameters;
Das Expires 19 April 2027 [Page 991]
Internet-Draft Protected AI Execution Finality October 2026
payload_digest;
applicable_delegation_reference;
applicable_computation_context;
authority_object_reference;
policy_epoch;
revocation_epoch;
authorization_state_version;
nonce;
expiry;
finality_sink_identity.
The applicable Authority Object determines which fields are
mandatory.
The descriptor represents the concrete effectuation request rather
than an abstract general permission.
11.24.14. WF-24.14 — Canonical Candidate Act Representation
In one illustrative implementation:
D_i = Canon_v(ID_i, SOURCE_i, ACT_i, TARGET_i, PARAM_i, CONTEXT_i,
STATE_i, SINK_i)
where:
D_i denotes the canonical descriptor for Candidate Act i;
ID_i denotes the operation identifier;
SOURCE_i denotes the authenticated requesting agent or workload;
ACT_i denotes the consequential operation class;
TARGET_i denotes destination or recipient;
PARAM_i denotes effectuation-relevant parameters;
CONTEXT_i denotes mandatory computation or delegation context;
Das Expires 19 April 2027 [Page 992]
Internet-Draft Protected AI Execution Finality October 2026
STATE_i denotes applicable protected authorization state; and
SINK_i denotes the designated Finality Sink.
An illustrative digest is:
h_i = H("DAS-MULTI-SINK-ACT-v1" || Encode(D_i))
The encoding must distinguish fields that materially affect
authorization.
The cryptographic construction is illustrative and does not replace
mandatory actual-operation verification.
11.24.15. WF-24.15 — Operation-Specific Authority Validation
PED-2410 obtains the Authority Object applicable to CA_i.
The Authority Object may specify:
(a) permitted operation class;
(b) source workload identity;
(c) destination or recipient;
(d) authorized purpose;
(e) permitted delegation scope;
(f) approved computation context;
(g) required protected state;
(h) usage limit;
(i) policy epoch;
(j) revocation conditions;
(k) freshness requirements; and
(l) designated Finality Sink.
The PED verifies the applicable authority independently for each
consequential operation.
Das Expires 19 April 2027 [Page 993]
Internet-Draft Protected AI Execution Finality October 2026
The existence of a valid capability for one operation does not
automatically satisfy another operation's required predicates.
11.24.16. WF-24.16 — Protected Authorization Predicate
An illustrative authorization predicate is:
V_i =
Pact_i AND
Pscope_i AND
Ptarget_i AND
Pcontext_i AND
Pstate_i AND
Psink_i
where:
V_i denotes authorization of Candidate Act i;
Pact_i verifies the actual operation;
Pscope_i verifies applicable permitted authority;
Ptarget_i verifies destination, recipient, or resource;
Pcontext_i verifies mandatory computation or delegation context;
Pstate_i verifies protected policy, revocation, nonce, freshness, and
usage conditions; and
Psink_i verifies the designated Finality Sink.
A valid operation-specific authorization does not independently
establish that the operation has already become effective.
Finality Sink verification remains required.
11.24.17. WF-24.17 — Protected Authorization-State Handling
Following successful operation-specific validation, PED-2410 performs
the protected-state operations required for CA_i.
Das Expires 19 April 2027 [Page 994]
Internet-Draft Protected AI Execution Finality October 2026
These may include:
(a) reserving an act-specific grant;
(b) consuming or registering a nonce;
(c) validating current policy state;
(d) checking the revocation epoch;
(e) updating protected usage;
(f) registering the Candidate Act Descriptor digest;
(g) associating the designated Finality Sink; or
(h) another required protected-state transition.
Where the grant is single-use or usage-bounded, the protected
mechanism prevents unauthorized duplicate consumption.
Where mandatory protected state cannot be established, the
corresponding capability remains unavailable.
11.24.18. WF-24.18 — Protected Validation-Evidence Commitment
EV-2413 generates or commits the applicable protected validation
evidence.
A non-limiting record comprises:
receipt_id;
candidate_act_id;
operation_descriptor_digest;
authority_object_reference;
source_workload_identity;
delegation_reference;
computation_context_reference;
protected_state_transition;
policy_epoch;
Das Expires 19 April 2027 [Page 995]
Internet-Draft Protected AI Execution Finality October 2026
nonce;
finality_sink_identity;
validation_result;
protected_authentication.
The record may comprise an AVR, LAVR, sealed validation record,
authenticated commitment, or another supported protected artifact.
Under enforcement point 68, operation-specific validation evidence is
committed before, or atomically with, availability of the operation-
specific execution capability.
The source-side validation record does not independently prove that
every later receiving-side consequential operation has completed.
11.24.19. WF-24.19 — Scoped Execution-Capability Release
CR-2414 releases or makes available an execution capability
corresponding to the validated Candidate Act.
The capability may bind:
(a) Candidate Act Descriptor digest;
(b) authorized operation;
(c) source workload identity;
(d) destination or recipient;
(e) permitted execution scope;
(f) protected validation-evidence reference;
(g) policy epoch;
(h) revocation epoch;
(i) nonce;
(j) expiry;
(k) usage limit; and
(l) designated Finality Sink.
Das Expires 19 April 2027 [Page 996]
Internet-Draft Protected AI Execution Finality October 2026
An illustrative representation is:
C_i = Sign_skPED(Encode(h_i, Receipt_i, Scope_i, State_i, Nonce_i,
Expiry_i, Sink_i))
The particular capability format may comprise a signature, MAC,
protected handle, sealed capability-table entry, or equivalent
authenticated mechanism.
The Finality Sink must enforce the required operation-specific and
state-dependent properties.
11.24.20. WF-24.20 — Independent Finality Sink Verification
The designated Finality Sink obtains or reconstructs the actual
operation presented for effectuation.
The verifier checks:
(a) capability authenticity;
(b) required descriptor correspondence;
(c) authorized operation scope;
(d) destination or recipient;
(e) applicable source identity;
(f) policy and revocation state;
(g) nonce and expiry;
(h) protected validation-state commitment;
(i) usage or consumption state; and
(j) designated Finality Sink identity.
The operation becomes effective only when the mandatory conditions
succeed.
A valid capability for another operation or another Finality Sink
does not independently satisfy the required verification.
Das Expires 19 April 2027 [Page 997]
Internet-Draft Protected AI Execution Finality October 2026
11.24.21. WF-24.21 — Effectuation Verification Predicate
An illustrative Finality Sink predicate is:
Permit_i =
Auth(C_i) AND
Match(C_i,Dactual_i) AND
ScopeValid(C_i) AND
StateValid(C_i) AND
SinkValid(C_i,FS_i)
where:
Permit_i denotes permission for Candidate Act i;
C_i denotes the operation-specific capability;
Dactual_i denotes the actual effectuation descriptor;
Auth verifies the capability;
Match verifies the required actual-operation correspondence;
ScopeValid verifies permitted operation scope;
StateValid verifies protected policy, revocation, evidence,
freshness, and usage conditions; and
SinkValid verifies that the capability authorizes Finality Sink i.
Only when the required predicate succeeds does the designated
Finality Sink permit effectuation.
11.24.22. WF-24.22 — Multi-Sink Capability Independence
in the implementation described by enforcement point 71, one agentic
workflow may comprise several independently consequential operations.
An operation-specific capability authorizes only the operation or
bounded set of operations expressly covered by its authenticated
scope.
For example:
Das Expires 19 April 2027 [Page 998]
Internet-Draft Protected AI Execution Finality October 2026
C_network authorizes the specified network transmission.
C_storage authorizes the specified persistent-state mutation.
C_payment authorizes the specified payment.
C_deployment authorizes the specified deployment effect.
The existence of C_network does not independently authorize
C_payment.
A valid Delegation Capability does not independently authorize any of
those downstream operations unless their separate required
authorization conditions are also satisfied.
An approved model-computation admission does not replace any
corresponding downstream execution capability.
11.24.23. WF-24.23 — Receiving-Side Finality
in the implementation described by enforcement point 72, the
downstream Finality Sink may comprise:
(a) a receiving service;
(b) a remote execution gateway;
(c) a protected database-commit interface;
(d) a payment execution interface;
(e) a hardware actuator; or
(f) a trusted connector.
The receiving-side Finality Sink reconstructs or verifies the actual
Candidate Act presented for effectuation.
It compares the operation with the operation-specific execution
capability and required protected validation-state commitment.
The receiving service does not rely solely on an upstream agent's
assertion that the operation was authorized.
The applicable enforcement boundary refuses the operation where
mandatory effectuation-relevant parameters differ.
Das Expires 19 April 2027 [Page 999]
Internet-Draft Protected AI Execution Finality October 2026
11.24.24. WF-24.24 — Remote Actual-Operation Descriptor
An illustrative receiving-side descriptor comprises:
operation_id;
actual_operation_class;
actual_recipient;
actual_destination;
actual_resource;
actual_parameters;
payload_digest;
required_state_version;
execution_scope;
finality_sink_identity.
A non-limiting expression is:
Dremote = Canon_v(OperationActual, RecipientActual, TargetActual,
ParametersActual, StateActual, SinkActual)
The receiving-side verifier compares Dremote with the authenticated
scope of the corresponding capability.
A mismatch in a required field causes refusal unless the Authority
Object expressly permits the relevant bounded variation.
A valid upstream operation identifier does not override a mismatch in
recipient, amount, resource, or other mandatory parameters.
11.24.25. WF-24.25 — Receiving-Side Verification Predicate
An illustrative predicate is:
PermitRemote =
Auth(C) AND
Match(C,Dremote) AND
Das Expires 19 April 2027 [Page 1000]
Internet-Draft Protected AI Execution Finality October 2026
ReceiptValid(C,R) AND
StateValid(C,S) AND
SinkValid(C,F)
where:
C denotes the operation-specific capability;
Dremote denotes the actual receiving-side operation;
R denotes the required protected validation evidence;
S denotes protected authorization state; and
F denotes the receiving-side Finality Sink.
The verifier refuses an operation that differs from the authorized
operation in a mandatory effectuation-relevant parameter, including:
(a) destination;
(b) recipient;
(c) operation type;
(d) protected state version; or
(e) applicable execution scope.
11.24.26. WF-24.26 — Source-Side Transmission and Receiving-Side
Commitment
A source-side network Finality Sink may permit an authorized request
to be transmitted.
The receiving system may subsequently perform a distinct database
modification, payment, storage commit, or another consequential
operation.
The source-side transmission authorization does not automatically
establish authority for the later receiving-side effect.
Where the receiving-side operation is separately governed, the
receiving Finality Sink requires the corresponding execution
capability.
Das Expires 19 April 2027 [Page 1001]
Internet-Draft Protected AI Execution Finality October 2026
For example:
CA_network → network Finality Sink → authorized transmission.
CA_database → database Finality Sink → separately authorized
persistent mutation.
The first operation can be authorized while the second remains non-
effective.
This distinction preserves the difference between permission to
communicate and permission to produce an irreversible downstream
state change.
11.24.27. WF-24.27 — Streaming Outputs and Partial Actions
in the implementation described by enforcement point 70, the
artificial-intelligence execution environment may produce:
(a) model-output tokens;
(b) partially generated tool arguments;
(c) decoded action fragments;
(d) incomplete API requests;
(e) command fragments;
(f) bounded streaming operations; or
(g) completed consequential requests.
The operation-classification component determines whether the
fragment remains internal data, forms part of an incomplete Candidate
Act, or constitutes a separately effective operation.
Where a fragment may cause a governed consequence, its applicable
Finality Sink verification remains mandatory.
The system does not treat every model token as necessarily requiring
a separate execution capability.
The finality granularity corresponds to the actual consequential
boundary and the scope of the protected authorization.
Das Expires 19 April 2027 [Page 1002]
Internet-Draft Protected AI Execution Finality October 2026
11.24.28. WF-24.28 — Buffering of Consequential Streaming Output
An illustrative streaming Candidate Act record comprises:
stream_id;
source_inference_id;
fragment_sequence;
fragment_digest;
operation_class;
candidate_act_id;
assembly_status;
finality_sink_id;
effectuation_status.
Incomplete operation fragments may remain buffered until enough
information exists to form the required Candidate Act Descriptor.
A bounded fragment that is independently consequential may require
its own protected authorization.
The system prevents a streaming tool request from becoming externally
effective merely because its bytes were produced by a validly
admitted model.
11.24.29. WF-24.29 — Model-Access Interruption and Buffered Operations
A model-access gate may deny or revoke future computation.
However, a consequential operation may already have been generated
and held by a tool runtime or execution environment.
Interruption of future model inference does not itself authorize the
buffered operation.
Nor does the interruption alone establish that a previously completed
external effect was prevented.
The buffered Candidate Act remains subject to its downstream Finality
Sink authorization.
Das Expires 19 April 2027 [Page 1003]
Internet-Draft Protected AI Execution Finality October 2026
Where the applicable policy also revokes the downstream authority,
the Finality Sink enforces that revocation before admitting the
operation.
11.24.30. WF-24.30 — Multi-Hop Agent Workflow
An agent may produce a sequence of operations across several service
boundaries.
A non-limiting sequence comprises:
AI computation → tool invocation → external network transmission →
receiving-side database request → persistent commit.
Each consequential stage may be subject to a different Finality Sink.
An upstream operation may prepare context for a later operation.
However, the resulting downstream authority must be established
through the applicable protected authorization conditions.
The workflow does not automatically propagate unrestricted capability
authority through every intermediate service.
A receiving service that becomes an independent actor may generate a
new Candidate Act requiring its own protected authorization.
11.24.31. WF-24.31 — Scoped Multi-Stage Authorization
An Authority Object may expressly permit a bounded multi-stage
workflow.
Such authority may specify:
(a) approved workflow graph;
(b) participating agents;
(c) permitted operation classes;
(d) designated Finality Sinks;
(e) allowed destinations;
(f) maximum usage;
(g) order constraints;
Das Expires 19 April 2027 [Page 1004]
Internet-Draft Protected AI Execution Finality October 2026
(h) policy epoch; and
(i) required protected state.
The system may use a set of operation-specific capabilities or an
expressly scoped multi-stage authorization representation.
Each designated Finality Sink nevertheless verifies the applicable
authorization for its own consequential boundary.
Authorization of the workflow as a whole is not interpreted as
unrestricted permission for unlisted operations or destinations.
11.24.32. WF-24.32 — Cross-Boundary Context Continuity
SC-2422 maintains or verifies the required relationship among
different stages of the workflow.
A protected workflow reference may contain:
workflow_id;
source_computation_reference;
delegation_reference;
candidate_act_ids;
authorized_transition_graph;
required_policy_epoch;
protected_state_version;
designated_finality_sinks.
The context may help establish that a downstream Candidate Act arose
from an approved workflow or delegated task.
However, context continuity does not itself substitute for operation-
specific execution authority.
A valid workflow identifier is not a universal capability for every
possible downstream effect.
Das Expires 19 April 2027 [Page 1005]
Internet-Draft Protected AI Execution Finality October 2026
11.24.33. WF-24.33 — Separate Credential Application
Where a workflow involves protected credential use, FS-2417 verifies
the authority required for the actual credential-mediated operation.
The agent may possess a credential reference or surrogate identifier
without having unrestricted access to the underlying protected
credential.
The protected credential-use interface verifies the permitted
operation, destination, credential scope, and required state.
Where the subsequent network transmission is separately governed,
FS-2415 independently verifies its corresponding authorization.
The system does not assume that protected credential application and
external network effectuation are always the same technical boundary.
They may be integrated within one protected component or implemented
through distinguishable enforcement functions.
11.24.34. WF-24.34 — Separate Persistent-State Commitment
A tool may prepare a database or file modification.
The operation is represented as a Candidate Act.
The protected authority validates the actual mutation and applicable
authorization conditions.
The persistent-state Finality Sink verifies the corresponding scoped
capability before committing the governed change.
Successful invocation of a tool or delivery of a network request does
not independently authorize the protected persistent-state mutation.
Where the data-storage service exposes a mandatory commit controller,
that interface may provide receiving-side execution-finality
enforcement.
11.24.35. WF-24.35 — Separate Payment Effectuation
An AI agent may prepare a payment request following an otherwise
authorized workflow.
The payment Candidate Act identifies the required recipient, amount,
currency, payment authority, protected state, and designated
financial Finality Sink.
Das Expires 19 April 2027 [Page 1006]
Internet-Draft Protected AI Execution Finality October 2026
The payment authority validates those parameters.
The corresponding capability is bound to the permitted operation.
The payment Finality Sink independently verifies the actual
transaction before completing the governed financial effect.
A valid network capability allowing communication with the payment
service does not independently authorize the payment.
Where the payment service cannot verify an operation-specific
capability and is outside the controlled receiving-side boundary, the
system cannot claim receiving-side finality merely from upstream
transmission permission.
11.24.36. WF-24.36 — Cross-Sink Capability Substitution
An attacker or compromised agent may attempt to reuse a valid
capability at another Finality Sink.
For example, a capability issued for one network operation may be
submitted to a database controller.
The receiving Finality Sink verifies the designated sink identity and
operation scope.
The capability fails the required binding.
The requested database operation is denied.
Similarly, a capability for one payment recipient cannot authorize
another recipient when exact recipient binding is mandatory.
The protection relies upon enforced operation-specific and sink-
specific verification, not merely upon the presence of cryptographic
authentication bytes.
11.24.37. WF-24.37 — Protected State Across Multiple Sinks
Where several Finality Sinks participate, the protected architecture
may maintain:
(a) common policy epochs;
(b) operation-specific grants;
(c) individual capability-consumption records;
Das Expires 19 April 2027 [Page 1007]
Internet-Draft Protected AI Execution Finality October 2026
(d) revocation conditions;
(e) protected validation-record references;
(f) sink-specific authorization state; and
(g) workflow-level outcome information.
An authorization valid at one sink does not automatically mean the
same state is valid at another sink.
The architecture may share a protected authority service while
maintaining separate operation-specific state.
Where current protected state is mandatory, each Finality Sink
verifies the conditions applicable to its own operation.
11.24.38. WF-24.38 — Revocation Across Consequential Boundaries
An Authority Object or protected grant may be revoked during
execution of a multi-stage workflow.
The system determines which pending and future operations are
affected.
For an operation that has not crossed its effectuation boundary, the
Finality Sink enforces the required current revocation condition.
For an operation that is already confirmed effective, revocation does
not retroactively prevent the completed consequence.
For an indeterminate operation, the system preserves the uncertainty
and consults applicable recovery rules.
The architecture does not presume that a revocation propagated to one
Finality Sink is instantly visible at every remote sink unless the
implementation establishes the required synchronization or freshness
guarantees.
11.24.39. WF-24.39 — Protected Operation Outcomes
OS-2423 maintains distinguishable status for each Candidate Act.
A non-limiting record comprises:
candidate_act_id;
workflow_id;
Das Expires 19 April 2027 [Page 1008]
Internet-Draft Protected AI Execution Finality October 2026
finality_sink_id;
authorization_status;
capability_status;
effectuation_status;
protected_state_version;
completion_evidence_reference;
last_attempt_id.
Status values may include:
NON_EFFECTIVE;
VALIDATING;
AUTHORIZED;
RESERVED;
EFFECTUATION_ATTEMPTED;
CONFIRMED_EFFECTIVE;
DENIED;
REVOKED;
INDETERMINATE.
One stage's confirmed effect does not automatically establish
successful completion of all later stages.
The system may preserve partial workflow completion and pending
downstream operations separately.
11.24.40. WF-24.40 — Crash and Recovery Across Multiple Finality Sinks
A distributed workflow may fail after an upstream effect but before a
downstream operation completes.
The recovery component identifies the status of each independently
governed Candidate Act.
Das Expires 19 April 2027 [Page 1009]
Internet-Draft Protected AI Execution Finality October 2026
For example:
CA_network may be confirmed transmitted.
CA_database may remain pending.
CA_payment may be indeterminate.
The system does not restart the entire workflow by automatically
repeating every operation.
Instead, it determines the protected authorization and completion
status applicable to each Candidate Act.
Pending operations are revalidated where required.
Consumed capabilities are not automatically reused.
Indeterminate external effects remain subject to protected
reconciliation and duplicate-effect prevention.
11.24.41. WF-24.41 — Receiving-Side Completion Reconciliation
Where supported, the receiving service may provide authenticated
completion information.
Such information may include:
(a) transaction identifier;
(b) operation digest;
(c) receiving-side commit record;
(d) protected completion receipt;
(e) idempotency status; or
(f) another reliable outcome reference.
The protected recovery mechanism verifies that the receiving-side
information corresponds to the original Candidate Act.
A successful receiving-side commitment may establish a completed
effect.
An unresolved status does not automatically authorize an
independently reusable capability.
Das Expires 19 April 2027 [Page 1010]
Internet-Draft Protected AI Execution Finality October 2026
The architecture does not assume exactly-once remote effectuation
without an appropriate receiving-side mechanism.
11.24.42. WF-24.42 — Illustrative End-to-End Enterprise Agent Workflow
An enterprise AI agent receives a user task requiring analysis of an
internal document followed by a database update and an external
notification.
First, the model-access component authorizes the required
computation.
The model generates the proposed workflow.
A subordinate agent may receive a bounded Delegation Capability
permitting document analysis.
The delegated agent reads permitted information and prepares a
database update.
The database update is classified as a Candidate Act.
The PED validates the proposed mutation.
The protected system commits the required validation evidence and
releases the database-specific execution capability.
The database Finality Sink verifies the actual record modification
before committing it.
The agent then prepares an external notification.
The notification is a separate Candidate Act.
The PED evaluates its destination, message scope, authority, current
state, and network Finality Sink.
A separate network capability becomes available only after successful
protected validation.
The network Finality Sink independently verifies the notification
before transmission.
The earlier model admission, Delegation Capability, and database-
commit capability do not independently authorize the external
notification.
Das Expires 19 April 2027 [Page 1011]
Internet-Draft Protected AI Execution Finality October 2026
11.24.43. WF-24.43 — Illustrative Remote Payment Verification
An AI agent prepares a payment instruction.
The network Finality Sink authorizes transmission of the payment
request to an approved payment service.
The receiving payment interface separately governs execution of the
financial transaction.
It reconstructs the actual recipient, amount, currency, operation
type, applicable state version, and authorized execution scope.
The receiving Finality Sink verifies the corresponding payment
capability and protected validation-state commitment.
If the amount or recipient differs from the authorized operation, the
payment Finality Sink refuses the operation.
The upstream network transmission authorization does not override the
receiving-side payment condition.
11.24.44. WF-24.44 — Illustrative Model-Quarantine Scenario
An AI model completes a valid inference and generates an external API
request.
The request remains buffered in a Non-Effective State.
A security component subsequently interrupts future model access.
The model cannot produce further governed inference through the
protected model-access path.
However, the buffered API request remains present.
The downstream API Finality Sink independently checks the operation-
specific execution capability.
If the capability is missing or invalid, the operation is refused.
The model-access interruption is not treated as a substitute for the
downstream check.
If an earlier API operation already became effective, its completed
consequence is preserved in the outcome record.
Das Expires 19 April 2027 [Page 1012]
Internet-Draft Protected AI Execution Finality October 2026
11.24.45. WF-24.45 — Illustrative Delegated-Agent Boundary
A primary AI agent receives permission to delegate a bounded research
task.
The delegation-acceptance Finality Sink verifies the Delegation
Capability.
A subordinate agent is activated within its permitted task and tool
scope.
The subordinate agent then attempts to export confidential data to an
external destination.
That proposed export is classified as a separate Candidate Act.
The downstream network Finality Sink requires the corresponding
operation-specific capability.
The original Delegation Capability does not independently authorize
the export.
If the proposed destination violates the applicable Authority Object,
the PED withholds the required capability and the network Finality
Sink refuses transmission.
11.24.46. WF-24.46 — Illustrative Cross-Sink Replay
A capability authorizes one database update.
The database Finality Sink verifies the operation and consumes the
corresponding protected usage state.
The agent subsequently attempts to reuse the capability for another
database record and at a different network interface.
The respective Finality Sinks verify current usage state, operation
descriptor, and sink identity.
The previous capability is no longer valid for the requested
operations.
The system refuses the unauthorized reuse.
A previously valid cryptographic authorization does not become
universal authority merely because the agent retains a copy.
Das Expires 19 April 2027 [Page 1013]
Internet-Draft Protected AI Execution Finality October 2026
11.24.47. WF-24.47 — Alternative Technical Implementations
Single-node implementation: One protected node performs Candidate Act
authorization and local Finality Sink verification for several
operation classes through separate protected interfaces.
Distributed PED implementation: A protected authority service issues
bounded capabilities verified by remote Finality Sinks.
Agent-tool implementation: A protected tool runtime independently
verifies execution authority for consequential tool operations.
Network implementation: A protected gateway, SmartNIC, or DPU
verifies the capability before transmission.
Database implementation: A protected commit controller verifies act-
specific authority before durable mutation.
Credential implementation: A protected broker verifies capability
scope before credential-mediated effectuation.
Payment implementation: A receiving payment interface verifies the
actual transaction before execution.
Hardware-actuation implementation: A protected controller verifies
the required capability before enabling a governed physical
operation.
Delegated-agent implementation: Delegation admission is protected
independently of downstream tool and external effects.
Model-access implementation: Computation-admission authority remains
separate from operation-specific effectuation authority.
Streaming implementation: Consequential fragments remain buffered
until the required bounded Candidate Act has been authorized.
Remote receiving-side implementation: The receiving system
reconstructs the actual operation and verifies the corresponding
execution capability.
These variants need not all appear together in every implementation.
The selected architecture must enforce the actual boundaries and
authorization relationships required under the specified enforcement
profile.
Das Expires 19 April 2027 [Page 1014]
Internet-Draft Protected AI Execution Finality October 2026
11.24.48. WF-24.48 — Failure and Fail-Closed Conditions
A governed operation remains non-effective or is refused when any
mandatory condition is absent, invalid, expired, revoked, replayed,
inconsistent, or unverifiable.
Non-limiting conditions include:
(a) invalid model-admission authority;
(b) invalid Delegation Capability;
(c) unauthorized subordinate-agent scope;
(d) incorrect operation classification;
(e) missing Candidate Act Descriptor;
(f) unauthorized operation type;
(g) destination mismatch;
(h) recipient mismatch;
(i) unauthorized resource;
(j) invalid purpose or execution scope;
(k) stale policy epoch;
(l) invalid revocation state;
(m) failed protected-state transition;
(n) failed required validation-evidence commitment;
(o) missing operation-specific capability;
(p) invalid capability authentication;
(q) consumed capability;
(r) nonce replay;
(s) Finality Sink identity mismatch;
(t) unauthorized cross-sink reuse;
Das Expires 19 April 2027 [Page 1015]
Internet-Draft Protected AI Execution Finality October 2026
(u) missing mandatory receiving-side validation;
(v) remote actual-operation mismatch;
(w) incomplete streaming operation;
(x) failure of mandatory non-bypassable enforcement; or
(y) unavailable required current protected authorization state.
Failure of an upstream computation, delegation, or network
authorization condition does not create an unrestricted alternative
downstream execution path.
11.24.49. WF-24.49 — PHOSITA Verification and Negative Tests
A person having ordinary skill in AI-agent architecture, distributed
authorization, service-mesh security, database transaction control,
protected cryptographic capabilities, and execution-finality
enforcement may verify the following cases.
Test 1 — Authorized model computation: Permit a valid model request
and verify successful computation admission.
Test 2 — Model admission without downstream capability: Produce a
consequential tool operation but omit its execution capability. The
downstream Finality Sink refuses it.
Test 3 — Valid delegation: Admit a bounded subordinate task using a
valid Delegation Capability.
Test 4 — Delegation without effectuation authority: Attempt an
unauthorized external operation under a valid Delegation Capability.
The applicable Finality Sink refuses the effect.
Test 5 — Network Finality Sink: Authorize one specified network
request and verify that only the matching operation is transmitted.
Test 6 — Database Finality Sink: Authorize a concrete persistent
mutation and verify its independent commit-boundary checks.
Test 7 — Payment Finality Sink: Present a valid payment capability
matching the actual transaction. The receiving-side protected
operation is permitted.
Test 8 — Payment recipient substitution: Change the recipient after
authorization. The receiving Finality Sink refuses the transaction.
Das Expires 19 April 2027 [Page 1016]
Internet-Draft Protected AI Execution Finality October 2026
Test 9 — Cross-sink capability reuse: Present a network capability at
a database Finality Sink. Required sink verification fails.
Test 10 — Cross-operation reuse: Present a capability for one
Candidate Act with another Candidate Act. Required descriptor
correspondence fails.
Test 11 — Consumed capability: Reuse a single-use capability after
valid consumption. Protected usage verification refuses the
operation.
Test 12 — Wrong workload: Present a capability through an
unauthorized workload where identity binding is mandatory.
Verification fails.
Test 13 — Stale policy state: Present an operation under an
incompatible current policy epoch. Effectuation is refused.
Test 14 — Revocation: Revoke an operation-specific grant before
effectuation. The Finality Sink refuses the affected operation.
Test 15 — Model interruption with buffered act: Interrupt future
inference while a Candidate Act remains buffered. The downstream
capability check remains mandatory.
Test 16 — Streaming partial operation: Present incomplete
consequential command fragments. The operation is held until the
required bounded Candidate Act can be verified.
Test 17 — Streaming operation mutation: Change a mandatory field
after authorization. The Finality Sink rejects the altered
operation.
Test 18 — Remote actual-operation reconstruction: Require a receiving
service to reconstruct the actual requested operation and verify the
corresponding capability.
Test 19 — Upstream request versus downstream commit: Permit an
upstream network request but withhold a separately required database-
commit capability. The database effect remains blocked.
Test 20 — Multiple independent sinks: Execute a workflow containing
several operation classes and confirm that each corresponding
Finality Sink enforces its own required authorization.
Test 21 — Delegation recursion: Attempt further delegated execution
beyond the permitted recursion or task scope. Required delegation
authorization fails.
Das Expires 19 April 2027 [Page 1017]
Internet-Draft Protected AI Execution Finality October 2026
Test 22 — Credential-mediated effect: Attempt protected credential
application without the required operation-specific capability. The
credential Finality Sink refuses the action.
Test 23 — Protected receipt mismatch: Present a valid-looking
capability associated with another operation's validation commitment.
Verification fails.
Test 24 — Concurrency: Submit competing operations against a
restricted grant. Protected state prevents unauthorized double
consumption.
Test 25 — Network bypass: Attempt an effect through an alternate
accessible network path. The governed operation remains blocked or
equivalently mediated.
Test 26 — Receiving-side bypass: Attempt to complete a governed
database or payment effect outside the protected receiving-side
interface. The specified enforcement configuration prevents or
equivalently mediates that path.
Test 27 — Partial workflow completion: Complete one authorized stage
while another remains pending. Preserve independent protected
outcome states.
Test 28 — Crash after upstream transmission: Interrupt the workflow
after network transmission but before receiving-side confirmation.
The system does not assume downstream completion.
Test 29 — Duplicate recovery: Retry an uncertain operation and
enforce the required original operation identity and protected
recovery conditions.
Test 30 — Wrong Finality Sink at recovery: Attempt to resume a
pending operation through a different unauthorized sink.
Verification fails.
Test 31 — Single-node multi-sink implementation: Verify separate
operation-specific finality functions implemented within one
protected node.
Test 32 — Distributed multi-sink implementation: Verify operation-
specific capabilities across several authenticated downstream
Finality Sinks.
Test 33 — Hardware actuation: Attempt a governed physical operation
without the required actuation capability. The hardware Finality
Sink remains non-admitting.
Das Expires 19 April 2027 [Page 1018]
Internet-Draft Protected AI Execution Finality October 2026
Test 34 — Finality Sink outage: Make one required receiving-side
Finality Sink unavailable. The corresponding operation remains
blocked while other independently authorized operations follow their
own applicable conditions.
Test 35 — Receiving-side state mismatch: Present a capability with an
incompatible protected state version. The receiving-side operation
is refused.
Test 36 — Upstream authorization-only architecture: Demonstrate that
an upstream allow decision, without required downstream capability
verification, is insufficient to satisfy the specified receiving-side
finality guarantee.
The tests may use controlled agent runtimes, model gateways,
delegation controllers, protected authorization services, credential
brokers, programmable network proxies, database mock services,
payment simulators, hardware-interlock emulators, and authenticated
receiving-side interfaces.
The actual demonstrated guarantees depend upon the implemented
enforcement boundaries and protected-state mechanisms.
11.24.50. WF-24.50 — Claim-Specific Technical Coverage
Enforcement Point 42 — Separation of Delegation from Downstream
Effectuation
WF-24.7 through WF-24.9 describe protected delegation acceptance
followed by independently governed consequential operations.
A Delegation Capability permits bounded delegation but does not
itself authorize downstream network, tool, file, credential, payment,
or other external effects.
Enforcement Point 57 — Separate Downstream Execution Authority
WF-24.10 through WF-24.12 describe classification of consequential
operations arising from admitted computation as separate Candidate
Acts requiring their own protected validation, scoped execution-
capability release, and Finality Sink verification.
Enforcement Point 68 — Model-Path and Effectuation-Path Dual
Authorization
WF-24.3, WF-24.10 through WF-24.21, and WF-24.29 describe the
protected model-access gate, downstream Candidate Act classification,
Non-Effective State holding, operation-specific validation-evidence
Das Expires 19 April 2027 [Page 1019]
Internet-Draft Protected AI Execution Finality October 2026
commitment, separate downstream Finality Sink verification, and
continued withholding of unverified operations after model-access
interruption.
Enforcement Point 69 — Inference-to-Act Context Binding
WF-24.11 describes the protected computation-admission record and its
association with the downstream Candidate Act Descriptor without
replacing operation-specific authority.
Enforcement Point 70 — Streaming Output and Partial-Action Control
WF-24.27 through WF-24.29 describe streaming fragments, bounded
consequential operations, buffering, and the requirement for
downstream Finality Sink verification notwithstanding interruption of
future inference.
Enforcement Point 71 — Multi-Sink Effectuation Classification
WF-24.4 through WF-24.6 and WF-24.22 describe identifying different
effectuation boundaries and refusing to treat a capability for one
operation or Finality Sink as authority for another.
Enforcement Point 72 — Remote Effectuation Verification
WF-24.23 through WF-24.26 describe receiving-side reconstruction of
the actual operation and verification against the corresponding
capability and protected validation-state commitment.
Unauthorized differences in recipient, destination, operation type,
state version, or execution scope cause refusal when those conditions
are mandatory.
Enforcement Point 95 — Model-Path Authorization Does Not Replace
Effectuation Authorization
WF-24.10, WF-24.29 and WF-24.44 describe independent downstream
authorization and continued protection of buffered Candidate Acts
after model-access interruption, quarantine, or revocation.
11.24.51. WF-24.51 — Technical Effect
The workflow establishes independent protected authorization for
distinct consequential boundaries within an AI-agent or distributed
service workflow.
Its operation comprises:
Das Expires 19 April 2027 [Page 1020]
Internet-Draft Protected AI Execution Finality October 2026
(a) authorized model computation or bounded delegation;
(b) generation of one or more consequential operations;
(c) classification of each operation according to its effectuation
boundary;
(d) interception and maintenance in a Non-Effective State;
(e) construction of an operation-specific Candidate Act Descriptor;
(f) validation of applicable authority, protected state, and
execution context;
(g) required validation-evidence commitment;
(h) issuance or availability of the corresponding scoped execution
capability;
(i) independent verification at the designated Finality Sink;
(j) receiving-side reconstruction or verification where applicable;
(k) controlled effectuation or fail-closed refusal; and
(l) protected handling of capability usage, revocation, recovery, and
uncertain downstream outcomes.
The architecture prevents computational permission, bounded
delegation, authenticated network communication, or authorization at
one Finality Sink from becoming unrestricted authority to complete
unrelated consequential operations.
The receiving-side embodiment places final authorization verification
at the boundary where the actual receiving-side operation becomes
effective.
The multi-sink embodiment associates each consequential operation
with the authority required by its own effectuation interface.
The streaming embodiment prevents consequential operation fragments
from escaping protected finality merely because they originated
during an admitted model computation.
The recovery embodiment preserves the independence of upstream and
downstream operation outcomes.
Computation is not authority to act.
Das Expires 19 April 2027 [Page 1021]
Internet-Draft Protected AI Execution Finality October 2026
Delegation acceptance is not downstream execution permission.
Model admission is not external-effect authorization.
Network transmission authority is not receiving-side database or
payment authority.
A capability issued for one Finality Sink is not automatically valid
at another.
The actual consequential operation must satisfy the authority
verified at its own Finality Sink.
12. Deployment Contexts
the proposed architecture is industrially applicable to artificial-
intelligence systems, autonomous computing, cybersecurity, cloud and
edge computing, confidential computing, cryptographic infrastructure,
telecommunications, financial technology, semiconductor technologies,
distributed computing, industrial automation, robotics, and other
digital or cyber-physical systems in which a computationally
generated operation must be independently authorized before producing
a consequential effect.
the architecture may be manufactured, implemented, deployed,
integrated, licensed, and commercially operated through software,
firmware, hardware, protected computing environments, cryptographic
enforcement components, network gateways, processors, accelerators,
storage controllers, secure elements, and combinations thereof. The
architecture may be incorporated into existing computing
infrastructures or implemented as a standalone protected execution-
authority system.
Artificial Intelligence, Autonomous Agents, and Agentic Computing
the architecture is applicable to AI assistants, autonomous software
agents, multi-agent frameworks, large language models, multimodal
models, reasoning systems, coding agents, research agents, enterprise
agents, browser agents, robotic agents, and AI-driven workflow
orchestration platforms. It provides protected authorization of
consequential operations generated by AI systems, including tool
invocation, external API access, network transmission, file
modification, software deployment, credential use, and persistent
data changes.
AI Model Serving, Inference Infrastructure, and AI Safety Platforms
Das Expires 19 April 2027 [Page 1022]
Internet-Draft Protected AI Execution Finality October 2026
the architecture may be integrated into model-serving gateways,
inference routers, model-access controllers, AI safety platforms,
agent-execution environments, and model-monitoring systems. It
distinguishes permission to perform model computation from authority
to execute consequential operations resulting from that computation.
Downstream Candidate Acts remain subject to protected finality
verification even when model access is interrupted, restricted,
quarantined, or revoked.
Cloud Computing, Hybrid Cloud, and Multi-Cloud Infrastructure
the architecture is applicable to public clouds, private clouds,
hybrid-cloud infrastructures, virtual machines, confidential virtual
machines, Kubernetes clusters, containerized workloads, serverless
execution platforms, distributed computing environments, and cloud-
native services. It supports authenticated workload identities,
protected policy-state synchronization, scoped execution
capabilities, migration controls, failover recovery, and prevention
of unauthorized restoration of previously consumed or revoked
execution authority.
Enterprise Information Technology and Business Automation
the architecture may be deployed in enterprise resource planning
systems, customer relationship management platforms, human-resource
management systems, document-management systems, enterprise workflow
engines, procurement platforms, inventory systems, and automated
business-process systems. It enables operation-specific
authorization of database modifications, financial approvals,
document publication, privileged service requests, and other
consequential enterprise operations.
Cybersecurity, Zero-Trust Architecture, and Privileged Access
Management
the architecture is applicable to zero-trust security architectures,
privileged access management, identity and access management,
endpoint protection, secure service gateways, network security,
security orchestration, and automated incident-response
infrastructure. It provides protected execution authority separate
from ordinary authentication and resource-access permissions,
including mandatory operation-specific checks, revocation, bounded
capabilities, replay protection, and fail-closed enforcement.
Software Development, DevOps, and Continuous Deployment
Das Expires 19 April 2027 [Page 1023]
Internet-Draft Protected AI Execution Finality October 2026
the architecture may be integrated into autonomous coding agents,
software-development environments, source-code management systems,
CI/CD pipelines, deployment controllers, package registries,
infrastructure-as-code systems, and automated software-maintenance
platforms. It may require protected authorization before
consequential actions such as modifying protected repositories,
publishing software artifacts, accessing signing credentials,
changing production configurations, deploying applications, or
modifying critical infrastructure.
Cryptographic Infrastructure, Key Management, and Digital Identity
the architecture is applicable to hardware security modules, trusted
execution environments, secure enclaves, cryptographic key-management
systems, certificate authorities, digital-signature services,
enterprise identity platforms, authentication services, and protected
credential brokers. It separates access to cryptographic material
from authority to perform particular consequential operations and
supports operation-bound key use, credential release, derived or
wrapped keys, protected authorization state, and cryptographically
scoped execution capabilities.
Confidential Computing and Privacy-Preserving Infrastructure
the architecture may be employed in confidential virtual machines,
secure enclaves, encrypted-memory systems, hardware-attested
computing environments, protected analytics platforms, and privacy-
preserving AI systems. It may enforce user-controlled data-access
conditions, trusted workload measurements, protected cryptographic
operations, and separate authorization before decrypted, processed,
or confidential information is disclosed or otherwise transferred
beyond its permitted boundary.
Semiconductor Manufacturing, Processor Architectures, and Hardware
Security
the architecture is applicable to semiconductor devices and computing
hardware incorporating CPUs, GPUs, TPUs, NPUs, FPGAs, ASICs, secure
processors, memory controllers, DMA engines, and protected input/
output controllers. Hardware finality gates and latches may enforce
scoped execution authority before protected transfers, accelerator
outputs, memory operations, peripheral commands, or other hardware-
mediated consequential effects.
AI Data Centers and High-Performance Computing
Das Expires 19 April 2027 [Page 1024]
Internet-Draft Protected AI Execution Finality October 2026
the architecture may be implemented in GPU clusters, AI training and
inference infrastructure, supercomputers, accelerator fabrics,
distributed memory systems, high-performance networking, and large-
scale computational facilities. It supports protected control of
accelerator data movement, RDMA and DMA operations, tensor exports,
inter-device transfers, model-artifact release, and other high-
throughput operations through bounded capabilities and hardware-
associated Finality Sinks.
Networking, SmartNICs, DPUs, and Network Security Infrastructure
the architecture is applicable to network interface controllers,
SmartNICs, data processing units, programmable switches, routers,
service-mesh gateways, network firewalls, secure proxies, load
balancers, and software-defined networking systems. These components
may verify operation-specific authorization before admitting network
transmissions, credential-mediated requests, protected service
invocations, or other governed communication operations.
Telecommunications and Mobile Network Infrastructure
the architecture may be applied to mobile core networks, 5G and 6G
systems, telecommunications gateways, network-function
virtualization, software-defined radio infrastructure, subscriber-
control systems, signaling networks, network-management platforms,
and autonomous telecommunications operations. It may govern
consequential routing changes, subscriber provisioning, network
configuration, protected signaling, service activation, and radio or
data-plane operations at the relevant execution boundary.
Satellite Communications, Aerospace, and Space Systems
the architecture may be integrated into satellite ground systems,
space communication gateways, spacecraft command infrastructure,
satellite payload controllers, remote sensing systems, and autonomous
aerospace platforms. It may enforce protected authorization before
consequential command transmission, payload activation, communication
routing, protected data release, or hardware actuation. Such
implementations may employ bounded authorization windows,
authenticated command descriptors, protected state, and fail-closed
command admission.
Banking, Payments, and Financial Technology
the architecture is industrially applicable to banking
infrastructure, digital payments, card-payment processing, electronic
funds transfer, payment gateways, transaction switches, financial
messaging platforms, and automated treasury operations. It may
Das Expires 19 April 2027 [Page 1025]
Internet-Draft Protected AI Execution Finality October 2026
provide operation-specific authorization of payment instructions,
recipient and amount verification, protected credential use,
transaction-state controls, bounded execution capabilities, and
independent verification at financial effectuation boundaries.
Capital Markets, Trading, and Financial Settlement
the architecture may be applied to automated trading systems,
brokerage infrastructure, securities exchanges, clearing systems,
settlement platforms, custody services, and AI-assisted financial
operations. It may require protected authorization before order
placement, transaction submission, asset movement, settlement
commitment, or other financial operations, with operation-specific
authority bound to applicable transaction parameters and protected
state.
Blockchain, Distributed Ledgers, and Digital Asset Systems
the architecture may be integrated into blockchain applications,
smart-contract interaction gateways, digital-asset custody
infrastructure, signing services, distributed-ledger transaction
systems, and decentralized application interfaces. It may enforce
protected authorization before cryptographic transaction signing,
transaction broadcasting, asset transfer, smart-contract invocation,
or ledger-affecting operations, while distinguishing permission to
generate a proposed transaction from authority to make that
transaction effective.
Databases, Data Centers, Storage, and Information Management
the architecture may be deployed in relational and distributed
databases, object-storage systems, file systems, data warehouses,
vector databases, backup infrastructure, and enterprise data-
management platforms. It may require protected execution authority
before persistent modification, deletion, publication, replication,
export, or commitment of protected information, including
verification at controlled storage or receiving-side commit
boundaries.
Healthcare, Hospitals, and Medical Technology
Das Expires 19 April 2027 [Page 1026]
Internet-Draft Protected AI Execution Finality October 2026
the architecture may be applied to healthcare information systems,
hospital-management platforms, electronic health records, diagnostic
AI, laboratory information systems, medical-device management, and
connected clinical infrastructure. It may control protected record
modifications, disclosure of sensitive patient information, clinical
workflow commands, and other consequential operations. Where applied
to medical devices, the protected authorization system may be
combined with device-specific safety controls, emergency operating
modes, and regulatory requirements.
Pharmaceuticals, Biotechnology, and Scientific Laboratories
the architecture may be employed in laboratory automation,
pharmaceutical manufacturing, biotechnology research infrastructure,
scientific instrumentation, automated experimentation systems, and
AI-assisted research environments. It may govern protected
experiment execution, instrument commands, sensitive dataset exports,
controlled process changes, and publication or release of
consequential research outputs.
Industrial Automation, Manufacturing, and Industry 4.0
the architecture is applicable to industrial control systems,
programmable logic controllers, supervisory control and data
acquisition systems, manufacturing execution systems, robotic
production lines, intelligent factories, industrial IoT platforms,
and autonomous machinery. It may require protected authorization
before industrial commands, production-parameter modifications,
machinery activation, firmware updates, or other consequential
control operations.
Robotics, Autonomous Vehicles, and Unmanned Systems
the architecture may be integrated into industrial robots, service
robots, autonomous mobile robots, unmanned aerial vehicles,
autonomous ground vehicles, maritime autonomous systems, and robotic
fleet-management platforms. It may distinguish computational
planning from authority to actuate motors, change operating modes,
initiate missions, deploy payloads, or perform other physical
operations, with enforcement at suitable protected command or
actuation boundaries.
Automotive, Connected Vehicles, and Transportation Infrastructure
the architecture may be used in connected-vehicle platforms,
automotive software systems, fleet-management infrastructure,
autonomous transportation systems, charging networks, railway
signaling, intelligent traffic systems, and logistics-control
Das Expires 19 April 2027 [Page 1027]
Internet-Draft Protected AI Execution Finality October 2026
platforms. It may govern consequential vehicle commands, firmware
updates, route-control operations, protected communications,
infrastructure configuration, and external service actions.
Implementations affecting safety-critical controls may incorporate
independent safety interlocks and sector-specific functional-safety
requirements.
Energy, Utilities, and Critical Infrastructure
the architecture may be applied to electrical power grids, smart
meters, renewable-energy installations, industrial energy
controllers, substations, water-treatment systems, oil and gas
infrastructure, pipeline monitoring, and other critical
infrastructure. It may enforce protected authorization before
configuration changes, actuator commands, operational setpoint
modifications, network-control operations, or release of privileged
infrastructure instructions.
Government, Public Administration, and Sovereign Digital
Infrastructure
the architecture may be employed in government computing
environments, public-sector cloud infrastructure, national digital
services, identity platforms, secure document systems, public
financial infrastructure, and sovereign AI deployments. It may
support protected execution authority, data-governance restrictions,
jurisdictional requirements, controlled credential use, audited
authorization state, and enforcement of consequential operations at
designated trusted boundaries.
E-Commerce, Retail, and Digital Marketplaces
the architecture may be integrated into AI shopping agents,
electronic-commerce platforms, retail automation, inventory-
management services, order-management systems, logistics platforms,
customer-service agents, and automated procurement systems. It may
distinguish product selection, quotation, and order preparation from
protected authority to place an order, authorize payment, modify
inventory, disclose customer information, or transmit an externally
binding instruction.
Supply Chain, Logistics, and Transportation Management
Das Expires 19 April 2027 [Page 1028]
Internet-Draft Protected AI Execution Finality October 2026
the architecture may be employed in warehouse automation, shipping
platforms, logistics optimization, freight-management systems,
procurement networks, supply-chain planning services, and autonomous
fulfillment platforms. It may require operation-specific
authorization for shipment release, inventory commitment, routing
instructions, purchase orders, warehouse-control commands, and
consequential coordination with third-party systems.
Media, Communications, and Digital Content Platforms
the architecture may be applied to digital publishing, content-
generation systems, media-processing infrastructure, messaging
platforms, streaming services, advertising systems, and automated
content-distribution networks. It may distinguish content generation
from authority to publish, distribute, disclose, transmit, or
irreversibly modify digital content, including controlled release
through network, storage, rendering, or distribution Finality Sinks.
Education, Research, and Academic Computing
the architecture may be integrated into educational AI systems,
scientific computing platforms, academic research infrastructure,
institutional data systems, research automation, and collaborative
computing environments. It may govern protected data export, tool
execution, controlled laboratory operations, privileged workflow
changes, and release of externally effective research or
administrative actions.
Internet of Things, Smart Buildings, and Connected Devices
the architecture may be employed in IoT gateways, smart homes,
commercial building-management systems, connected appliances, access-
control platforms, environmental monitoring, and distributed device-
management systems. It may require protected authorization before
device configuration, remote command execution, firmware
installation, access-control changes, sensor-data disclosure, or
other consequential device operations.
Edge Computing and Distributed Autonomous Infrastructure
the architecture may be implemented in edge servers, embedded
controllers, remote gateways, mobile computing platforms, distributed
AI inference systems, and intermittently connected infrastructure.
It may maintain bounded execution authority using authenticated
workload identity, protected authorization state, freshness
conditions, scoped capabilities, and controlled fail-closed operation
during network interruptions or recovery.
Das Expires 19 April 2027 [Page 1029]
Internet-Draft Protected AI Execution Finality October 2026
Identity, Privacy, Data Protection, and Regulated Data Processing
the architecture may be applied to identity-verification
infrastructure, privacy-preserving applications, consent-management
systems, cross-border data-processing platforms, regulated data
repositories, and automated data-governance systems. It may bind
consequential data operations to applicable purpose, jurisdiction,
consent, recipient, data scope, authority state, and protected
effectuation conditions.
Emergency Services and Public-Safety Infrastructure
the architecture may be integrated into emergency communication
networks, public-warning systems, critical incident-management
platforms, disaster-response coordination infrastructure, and
protected command services. It may support separately authorized
emergency execution modes or Safe-Baseline operations while
preserving authenticated authority, bounded scope, protected state,
and the applicable safety and availability requirements.
Cross-Industry Applications and Deployment Flexibility
The foregoing industrial applications are illustrative and non-
limiting. the architecture may also be applied to any computerized,
networked, autonomous, cryptographic, transactional, industrial, or
cyber-physical system in which an operation is generated or prepared
by one component while protected authority to complete that operation
is established and verified by another protected function.
The Protected Enforcement Domain and Finality Sink may be implemented
within the same protected device, within different protected
components of a computing system, or across authenticated distributed
infrastructure. The system may operate entirely in software, in
hardware, or through combinations of firmware, secure processors,
hardware security modules, virtual machines, protected gateways,
network interfaces, and external receiving-side enforcement
components.
The architecture is not dependent upon a particular AI model, cloud
provider, processor family, cryptographic primitive, operating
system, industry protocol, or physical deployment arrangement.
Different industrial implementations may employ different Authority
Objects, protected predicates, capability representations,
validation-evidence mechanisms, trust boundaries, and Finality Sink
configurations according to their operational and regulatory
requirements.
Das Expires 19 April 2027 [Page 1030]
Internet-Draft Protected AI Execution Finality October 2026
the architecture is capable of practical industrial implementation
using computing processors, memory devices, cryptographic hardware,
secure execution environments, protected authorization-state stores,
network interfaces, storage systems, and controlled effectuation
mechanisms. Its components may be manufactured as semiconductor
devices, integrated into enterprise and industrial computing systems,
supplied as protected software or firmware, or deployed as managed
computing and security infrastructure.
The industrial utility of the architecture lies in its ability to
maintain a protected technical distinction between computation and
consequential execution, ensuring that a proposed operation does not
acquire the governed practical effect merely because an artificial-
intelligence agent, software process, authenticated service, or
computational system is capable of generating or requesting it.
The fundamental industrial principle implemented by the architecture
is that computation is not authority to act. A consequential
operation becomes effective only upon satisfaction of the applicable
protected authorization conditions and verification at the designated
execution-finality boundary.
13. Technical Enforcement Points and Boundary Conditions
The following numbered enforcement points describe proposed
implementation behavior and verification conditions extracted from
the accompanying architecture. They are engineering design points,
not legal rights, and do not by themselves define an interoperable
protocol or assert implementation conformance. Each point applies
where its corresponding mechanism is selected. An implementation
must demonstrate the actual enforcement and trust properties asserted
for its governed effectuation paths.
13.1. EP-01: Protected AI-Agent Sandbox Egress Finality System
An implementation for controlling externally effective operations
generated by an artificial-intelligence agent, uses the following
components and conditions:
a sandboxed execution environment configured to execute an
artificial-intelligence agent, an agentic workflow, or an associated
tool, and to generate or prepare a proposed operation comprising at
least one of a network request, application programming interface
call, connector invocation, shell command, file operation, browser
automation action, credential request, or host-system operation;
Das Expires 19 April 2027 [Page 1031]
Internet-Draft Protected AI Execution Finality October 2026
an interception component positioned between the sandboxed execution
environment and an effect-capable host or external execution
interface, the interception component being configured to intercept
the proposed operation before effectuation and represent the proposed
operation as a Candidate Sandbox Egress Act maintained in a Non-
Effective State;
a Candidate Sandbox Egress Act Descriptor comprising machine-
verifiable information identifying the proposed operation, a
requesting execution context, an intended destination or execution
target, an applicable authority scope, and an execution-finality
boundary;
a Protected Enforcement Domain isolated from execution authority
controlled by the artificial-intelligence agent, the Protected
Enforcement Domain being configured to:
obtain the Candidate Sandbox Egress Act Descriptor and an applicable
Sandbox Egress Authority Object;
validate the Candidate Sandbox Egress Act against applicable
operation, authority, destination, purpose, scope, runtime-context,
policy-state, and freshness predicates;
prevent the artificial-intelligence agent from independently
conferring execution authority upon the Candidate Sandbox Egress Act;
generate or commit protected validation evidence corresponding to the
Candidate Sandbox Egress Act before, or atomically with, availability
of execution-enabling authority; and
release or make available a scoped, non-bearer Sandbox Egress
Capability only upon successful satisfaction of the applicable
protected validation predicates;
a Finality Sink associated with a host execution interface, network-
egress interface, application programming interface gateway,
credential-release interface, file-operation interface, or other
effectuation boundary, the Finality Sink being configured to
independently verify the Sandbox Egress Capability against the
Candidate Sandbox Egress Act and its applicable execution context
before permitting effectuation;
Under this condition, the Finality Sink is arranged such that the
Candidate Sandbox Egress Act cannot become externally effective
through the governed execution path solely by virtue of its
generation, preparation, invocation, or approval by the artificial-
intelligence agent; and
Das Expires 19 April 2027 [Page 1032]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, absence, invalidity, expiry, revocation, scope
mismatch, or failed verification of the Sandbox Egress Capability
causes the corresponding Candidate Sandbox Egress Act to remain non-
effective through fail-closed enforcement at the applicable Finality
Sink.
13.2. EP-02: Sandbox Boundary Interception
In this configuration, the interception component comprises at least
one of a container-runtime hook, hypervisor trap, operating-system
policy broker, kernel broker, seccomp filter, eBPF program, shell
wrapper, browser automation controller, file-system policy module,
network-egress proxy, or application programming interface gateway.
13.3. EP-03: Concrete Act Descriptor
In this configuration, the Candidate Sandbox Egress Act Descriptor
further identifies one or more of an agent identity, sandbox
identity, host identity, command digest, command class, file path,
network destination, application programming interface endpoint,
credential scope, browser action, package identity, input provenance,
tool identity, risk class, policy epoch, nonce, expiry, or Finality
Sink identity.
13.4. EP-04: Intent, Logic and Behavioral Verification
In this configuration, the Protected Enforcement Domain validates one
or more of:
an Algorithmic Intent Fingerprint representing an authorized purpose
of the sandboxed execution environment;
an Algorithmic Logic Fingerprint representing an approved workflow,
container image, tool graph, command policy, package set, or browser
automation policy; and
a Runtime Behavioral Descriptor representing observed runtime
behavior associated with the Candidate Sandbox Egress Act;
Under this condition, failure of a required validation condition
causes withholding of the Sandbox Egress Capability.
Das Expires 19 April 2027 [Page 1033]
Internet-Draft Protected AI Execution Finality October 2026
13.5. EP-05: Untrusted Content and Taint-Lineage Governance
In this configuration, the Runtime Behavioral Descriptor or Candidate
Sandbox Egress Act Descriptor includes provenance or taint-lineage
information identifying influence from one or more of a user
instruction, webpage, retrieved document, email, tool response,
package metadata, model-generated output, memory item, or another
agent message;
Under this condition, the Protected Enforcement Domain evaluates
whether the identified influence is authorized to contribute to the
proposed operation; and
Under this condition, unauthorized promotion of untrusted content
into execution authority results in withholding of the Sandbox Egress
Capability.
13.6. EP-06: Network Egress Finality
In this configuration, the Candidate Sandbox Egress Act comprises a
network transmission or application programming interface request;
Under this condition, the Protected Enforcement Domain validates the
requested destination, endpoint, network route, operation class, and
authorized execution scope; and
Under this condition, a network-egress Finality Sink refuses
forwarding or transmission unless the corresponding Sandbox Egress
Capability verifies.
13.7. EP-07: Credential Broker Finality
In this configuration, the Candidate Sandbox Egress Act comprises a
credential request or credential-mediated external-service operation;
Under this condition, the Protected Enforcement Domain validates a
credential scope associated with the requested operation; and
Under this condition, a credential broker or credential-release
interface refuses to release, grant, or enable credential-mediated
authority unless the corresponding scoped Sandbox Egress Capability
verifies.
Das Expires 19 April 2027 [Page 1034]
Internet-Draft Protected AI Execution Finality October 2026
13.8. EP-08: File, Shell and Host-System Enforcement
In this configuration, the Candidate Sandbox Egress Act comprises a
shell command, file write, package installation, system call, host
application programming interface invocation, or persistent-state
modification;
Under this condition, the Protected Enforcement Domain validates an
applicable command class, target path, package identity, host
operation, or resource scope; and
Under this condition, the applicable Finality Sink refuses the
requested execution or state mutation unless the corresponding
Sandbox Egress Capability verifies.
13.9. EP-09: Protected Human Approval
In this configuration, a Candidate Sandbox Egress Act requiring human
approval remains in the Non-Effective State pending receipt of an
approval artifact;
Under this condition, the approval artifact is bound to the Candidate
Sandbox Egress Act Descriptor and validated by the Protected
Enforcement Domain; and
Under this condition, the human approval artifact is insufficient by
itself to enable effectuation without successful protected validation
and verification of the corresponding Sandbox Egress Capability at
the Finality Sink.
13.10. EP-10: Agent-Initiated Policy Mutation
In this configuration, the artificial-intelligence agent proposes
modification of an execution policy, tool policy, retrieval policy,
safety policy, delegation policy, model configuration, or workflow
configuration;
Under this condition, the proposed modification is classified as a
Candidate Self-Mutation Act maintained in a Non-Effective State;
Under this condition, the Protected Enforcement Domain validates a
Self-Mutation Authority Object identifying an existing policy state,
proposed policy state, permitted mutation class, applicable approval
requirement, policy epoch, and revocation state; and
Under this condition, activation of the proposed modification is
refused unless a corresponding Self-Modification Capability is
released and verified.
Das Expires 19 April 2027 [Page 1035]
Internet-Draft Protected AI Execution Finality October 2026
13.11. EP-11: Sub-Agent Delegation
In this configuration, a proposed delegation to a subordinate
artificial-intelligence agent is classified as a Candidate Delegation
Act;
Under this condition, the Protected Enforcement Domain validates a
Delegation Authority Object identifying a parent agent, delegated
agent, permitted objective, tool class, data scope, resource scope,
time window, recursion limit, or execution budget; and
Under this condition, delegated execution authority is bounded by a
corresponding Delegation Capability and does not independently
authorize an operation outside the validated delegation scope.
13.12. EP-12: Continuous Egress Validation
In this configuration, successive sandbox-boundary-crossing commands,
network requests, application programming interface calls, or file
operations are subjected to respective protected validation events;
Under this condition, the protected validation events are associated
with micro-validation receipts or an updated protected receipt-chain
state; and
Under this condition, the Protected Enforcement Domain withholds
further Sandbox Egress Capabilities upon detection of runtime
behavior inconsistent with an authorized execution scope.
13.13. EP-13: Revocation and Policy-Epoch Enforcement
In this configuration, the Sandbox Egress Capability is bound to a
policy epoch, revocation state, nonce, expiry condition, or protected
authorization state;
Under this condition, a change invalidating a required bound
condition prevents further effectuation under the affected
capability; and
Under this condition, renewed authorization requires validation
against current protected state.
Das Expires 19 April 2027 [Page 1036]
Internet-Draft Protected AI Execution Finality October 2026
13.14. EP-14: Hardware-Rooted Enforcement
In this configuration, the Protected Enforcement Domain or Finality
Sink comprises at least one of a trusted execution environment,
hardware security module, secure enclave, secure kernel broker,
hypervisor-isolated domain, SmartNIC, data processing unit, protected
gateway processor, or firmware-protected controller;
and in which an execution-enabling latch, host execution gate,
credential-release gate, or network-forwarding gate remains disabled
absent successful Sandbox Egress Capability verification.
13.15. EP-15: Browser and Computer-Use Finality
In this configuration, the Candidate Sandbox Egress Act comprises a
browser automation action, form submission, graphical-interface
operation, or computer-use action;
Under this condition, the Protected Enforcement Domain validates a
Screen-State Finality Object identifying a contemporaneous screen
state, semantic target, application context, authority state, and
Finality Sink identity; and
Under this condition, a browser execution interface or computer-use
Finality Sink refuses effectuation when the validated screen-state or
action context does not correspond to the operation presented for
effectuation.
13.16. EP-16: Autonomous Commerce
In this configuration, the Candidate Sandbox Egress Act comprises an
autonomous purchase, payment instruction, offer, negotiation, bid, or
commerce transaction;
Under this condition, the Protected Enforcement Domain validates a
commerce authority object against an applicable counterparty, item or
service scope, price or spending constraint, permitted purpose,
policy epoch, nonce, and execution-finality boundary; and
Under this condition, a commerce or payment Finality Sink refuses
effectuation unless a corresponding scoped Commerce Actuation
Capability verifies.
Das Expires 19 April 2027 [Page 1037]
Internet-Draft Protected AI Execution Finality October 2026
13.17. EP-17: Privacy-Preserving Validation Receipt
In this configuration, the protected validation evidence comprises an
Egress LAVR or zero-knowledge validation receipt configured to
establish satisfaction of required authorization predicates while
withholding one or more private user attributes, proprietary workflow
details, or sensitive internal task parameters from an unauthorized
relying component.
13.18. EP-18: Fail-Closed Denial and Containment
In this configuration, failure of an authority, scope, provenance,
runtime-behavior, destination, freshness, or Finality Sink
verification condition causes the Candidate Sandbox Egress Act to be
blocked, withheld, quarantined, sanitized, simulated without external
effect, recorded as denied, or directed for additional human review;
Under this condition, such handling does not itself grant execution
authority for the rejected operation.
13.19. EP-19: Canonical Authorization-to-Execution Binding
In this configuration, the Protected Enforcement Domain constructs a
canonical execution descriptor from an intercepted operation, the
canonical execution descriptor including an operation identifier,
requesting execution context, executable or connector identity,
intended destination, operation parameters, applicable permission
scope, and authorization-state version;
Under this condition, an authorization commitment is generated over
the canonical execution descriptor; and
Under this condition, the Finality Sink reconstructs or verifies a
corresponding execution descriptor immediately before effectuation
and refuses the operation when the execution descriptor presented for
effectuation does not correspond to the authorization commitment.
13.20. EP-20: Protected Grant-State Consumption
In this configuration, the Protected Enforcement Domain maintains a
protected authorization-state record identifying an active grant,
authorized operation, validity interval, permitted usage count, and
revocation state;
Under this condition, consumption of a grant for a consequential
operation is performed through an atomic protected-state transition
preventing the same grant instance from enabling an unauthorized
duplicate effect; and
Das Expires 19 April 2027 [Page 1038]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, failure to establish the required state
transition causes withholding of the corresponding execution-enabling
authority.
13.21. EP-21: Atomic Credential-Release Transaction
In this configuration, the Candidate Sandbox Egress Act requires a
credential protected from the sandboxed execution environment;
Under this condition, a credential-release component receives the
validated execution descriptor and an authorization commitment
associated with the protected grant-state transition;
Under this condition, release or application of the credential is
conditioned on correspondence between the exact operation presented
for effectuation and the authorization commitment; and
Under this condition, the credential-release component prevents the
credential from becoming available for a different operation,
destination, authorization scope, or grant-state instance.
13.22. EP-22: Privileged Connector Verification
In this configuration, a privileged connector execution component is
isolated from the sandboxed execution environment and communicates
with the Protected Enforcement Domain or a credential-release
component through an authenticated inter-component interface;
Under this condition, the privileged connector execution component
independently verifies an authorization commitment or execution-
enablement artifact associated with the specific operation; and
Under this condition, the privileged connector execution component
refuses an external service invocation when the requesting component,
operation descriptor, grant state, or execution-enablement artifact
fails verification.
13.23. EP-23: Destination Resolution and Redirect Consistency
In this configuration, the canonical execution descriptor further
binds an authorized destination to one or more of a hostname,
resolved network address, destination address class, port, transport
protocol, request method, resource path, or final routing
destination;
Under this condition, a destination change caused by name resolution,
redirection, routing modification, or connection reuse is evaluated
against the authorization commitment before transmission; and
Das Expires 19 April 2027 [Page 1039]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, a destination mismatch that cannot be validated
under the authorized scope prevents effectuation until a
corresponding protected validation succeeds.
13.24. EP-24: Crash, Retry and Duplicate-Effect Protection
In this configuration, the Protected Enforcement Domain maintains a
protected operation-state machine representing at least a pending
state, an authorized state, a consumption-reserved state, and a
terminal state associated with a Candidate Sandbox Egress Act;
Under this condition, a retry following timeout, process failure, or
interrupted communication is correlated with the original operation
identifier and protected authorization state; and
Under this condition, uncertainty regarding whether an earlier
attempt became externally effective prevents issuance of an
independently reusable authorization for the same consequential act
unless a protected recovery predicate establishes that duplicate
effectuation will not occur.
13.25. EP-25: Process-Lineage Authority Degradation
In this configuration, the sandboxed execution environment maintains
a protected influence state associated with a process, subprocess,
session, or execution lineage;
Under this condition, the influence state is updated upon a defined
interaction with untrusted information and propagated to a descendant
execution context according to a protected propagation rule;
Under this condition, the updated influence state modifies the
execution scope or validation requirements applicable to a subsequent
Candidate Sandbox Egress Act; and
Under this condition, the subsequent Candidate Sandbox Egress Act
cannot obtain a capability relying on a broader, previously
applicable authorization scope when the updated influence state
requires restricted authorization.
13.26. EP-26: Policy Mutation Activation Interlock
In this configuration, a proposed policy modification is represented
by a pre-mutation policy digest, a proposed post-mutation policy
digest, and an authorized transition descriptor;
Das Expires 19 April 2027 [Page 1040]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, an activation component verifies that the
current policy state corresponds to the pre-mutation policy digest
and that a protected approval authorizes the transition to the post-
mutation policy digest; and
Under this condition, the policy modification becomes effective only
through an atomic or ordered protected activation transition that
invalidates execution authority inconsistent with the resulting
policy state.
13.27. EP-27: Cross-Component Finality Consistency
In this configuration, two or more protected execution components
participate in authorizing, releasing, forwarding, or effectuating
the same Candidate Sandbox Egress Act;
Under this condition, each component verifies an operation-specific
commitment corresponding to the same authorized operation, scope,
authorization-state version, and finality boundary; and
Under this condition, inconsistent commitments, stale authorization
state, duplicate consumption, or disagreement concerning the
authorized operation prevents final effectuation until the
inconsistency is resolved through a protected validation or recovery
procedure.
13.28. EP-28: Transaction-Bound Agent Authorization and Credential
Effectuation System
An implementation for controlling credential-mediated operations
generated by an artificial-intelligence agent, uses the following
components and conditions:
an agent execution environment configured to generate a proposed
external operation directed to a service, connector, network
destination, or application programming interface;
a protected authorization component outside execution authority
controlled by the artificial-intelligence agent;
an operation-normalization component configured to construct a
canonical operation descriptor representing a concrete proposed
operation, including a requesting execution context, an operation
class, an intended destination, an operation parameter set, and an
applicable credential or permission scope;
Das Expires 19 April 2027 [Page 1041]
Internet-Draft Protected AI Execution Finality October 2026
a protected authorization-state store configured to maintain an
authorization record corresponding to the canonical operation
descriptor, the authorization record including a validity condition,
grant-state identifier, and consumption condition;
a credential-effectuation component isolated from direct control by
the artificial-intelligence agent and configured to obtain or use a
protected credential required for executing the proposed external
operation;
an execution-verification component configured to compare the
operation presented for effectuation against the canonical operation
descriptor and a current protected authorization state;
Under this condition, the protected authorization component and the
credential-effectuation component are configured to enforce a
transaction-bound dependency such that the protected credential
cannot be applied to effectuate the proposed operation unless:
the authorization record corresponds to the operation presented for
effectuation;
the required validity and protected grant-state conditions are
satisfied;
a required consumption or reservation transition is established for
the operation; and
the execution-verification component confirms that the operation
remains within the authorized scope; and
Under this condition, failure of any required condition prevents
credential-mediated effectuation through the governed execution path,
irrespective of whether the artificial-intelligence agent possesses a
reference to the service, destination, credential placeholder,
connector, or earlier authorization decision.
13.29. EP-29: Protected Credential Substitution
In this configuration, the agent execution environment is supplied
with a non-authoritative credential reference or surrogate credential
that does not independently enable the external operation;
Under this condition, the credential-effectuation component resolves
the reference or surrogate to protected credential material only
after satisfaction of the transaction-bound dependency; and
Das Expires 19 April 2027 [Page 1042]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, the credential-effectuation component applies
the protected credential exclusively to the corresponding validated
operation without releasing reusable protected credential material
into the agent execution environment.
13.30. EP-30: Independent Executor Attestation
In this configuration, the execution-verification component is
associated with a privileged connector, network proxy, gateway, host
worker, or protected execution interface;
Under this condition, the execution-verification component verifies
an identity or attestation of the component requesting credential-
mediated effectuation; and
Under this condition, the authorization record is rejected when a
requesting component identity, authenticated execution context, or
authorization-state binding does not correspond to the validated
operation.
13.31. EP-31: Protected Effectuation Outcome State
In this configuration, the protected authorization-state store
maintains an operation-specific effectuation status identifying
whether the proposed external operation remains pending, has been
reserved for effectuation, has been confirmed effective, has been
denied, or has an indeterminate completion status;
Under this condition, subsequent execution attempts are evaluated
against the operation-specific effectuation status; and
Under this condition, a subsequent attempt is prevented from creating
an unauthorized duplicate external effect when a prior attempt has
consumed or reserved the relevant execution authority.
13.32. EP-32: Method of Protected Agent Egress Finality
An implementation for controlling externally effective operations
generated by an artificial-intelligence agent, follows these
processing stages:
executing an artificial-intelligence agent within a sandboxed
execution environment;
intercepting a proposed operation generated by the artificial-
intelligence agent before the operation crosses an externally
effective execution boundary;
Das Expires 19 April 2027 [Page 1043]
Internet-Draft Protected AI Execution Finality October 2026
representing the proposed operation as a Candidate Sandbox Egress Act
maintained in a Non-Effective State;
generating a machine-verifiable descriptor identifying the Candidate
Sandbox Egress Act, its intended effect, applicable scope, and
Finality Sink;
validating the Candidate Sandbox Egress Act within a Protected
Enforcement Domain isolated from execution authority controlled by
the artificial-intelligence agent;
generating or committing protected validation evidence before, or
atomically with, availability of a scoped, non-bearer execution
capability corresponding to the validated Candidate Sandbox Egress
Act;
presenting or making available the scoped execution capability for
verification at the applicable Finality Sink;
independently verifying, at the Finality Sink, correspondence between
the scoped execution capability, the Candidate Sandbox Egress Act,
the authorized scope, and required current protected state;
permitting effectuation only upon successful Finality Sink
verification; and
otherwise withholding, denying, quarantining, or retaining the
Candidate Sandbox Egress Act in a Non-Effective State so that the
artificial-intelligence agent cannot independently complete the
externally effective operation through the governed execution path.
13.33. EP-33: State-Bound Finality and Replay Protection
In this configuration, :
binding the scoped execution capability to a nonce, policy epoch,
authorization-state version, operation descriptor, and Finality Sink
identity;
verifying the bound values against a current execution context
immediately before effectuation;
consuming, invalidating, or advancing a protected capability-usage
state before, or atomically with, permitted effectuation; and
refusing replay, cross-destination substitution, cross-sink use, or
subsequent execution under a capability whose protected consumption
state no longer permits the requested operation.
Das Expires 19 April 2027 [Page 1044]
Internet-Draft Protected AI Execution Finality October 2026
13.34. EP-34: Protected Self-Modification Finality System
An implementation for governing modifications proposed by an
artificial-intelligence agent to its own execution environment or
authority configuration, uses the following components and
conditions:
an artificial-intelligence execution environment configured to
execute an agent, agentic workflow, model runtime, tool runtime, or
autonomous coding system;
a mutation interception component configured to intercept a proposed
modification to at least one of an execution policy, system
instruction, tool-access policy, memory policy, retrieval policy,
safety policy, delegation policy, planner policy, model
configuration, adapter state, or workflow graph before the
modification becomes effective;
a Candidate Self-Mutation Act Descriptor identifying the proposed
modification, a pre-mutation configuration, a proposed post-mutation
configuration, a mutation class, an affected execution environment,
and an applicable mutation-activation boundary;
a Protected Enforcement Domain isolated from execution authority
controlled by the artificial-intelligence agent, the Protected
Enforcement Domain being configured to:
maintain or obtain a Self-Mutation Authority Object;
validate the Candidate Self-Mutation Act against an applicable
authorized mutation class, policy state, safety baseline, runtime-
context condition, and revocation condition;
evaluate applicable Algorithmic Intent Fingerprint, Algorithmic Logic
Fingerprint, or Runtime Behavioral Descriptor conditions;
generate or commit protected validation evidence corresponding to the
Candidate Self-Mutation Act; and
release a scoped Self-Modification Capability only when the required
validation predicates have been satisfied;
a mutation-activation Finality Sink associated with a model runtime,
policy manager, agent orchestrator, tool gateway, retrieval system,
or memory manager, the mutation-activation Finality Sink being
configured to verify the Self-Modification Capability against the
proposed modification and current activation context before applying
the modification; and
Das Expires 19 April 2027 [Page 1045]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, the proposed modification remains in a Non-
Effective State, and the mutation-activation Finality Sink refuses
activation, when the Self-Modification Capability is absent, invalid,
expired, revoked, or inconsistent with the proposed modification.
13.35. EP-35: Before-and-After Policy Binding
In this configuration, the Self-Mutation Authority Object includes a
current policy digest, a proposed policy digest, an approved mutation
class, an Algorithmic Logic Fingerprint before mutation, an
Algorithmic Logic Fingerprint after mutation, a policy epoch, and a
nonce;
Under this condition, the mutation-activation Finality Sink verifies
correspondence between the actual policy transition and the protected
authorization state before activating the proposed policy.
13.36. EP-36: Evaluation and Regression Evidence
In this configuration, the Protected Enforcement Domain additionally
validates at least one of a regression-test digest, evaluation
digest, approved safety baseline, tool-permission change, retrieval-
permission change, prohibited mutation class, or proposed authority
expansion;
Under this condition, failure of a required predicate prevents
issuance of the Self-Modification Capability.
13.37. EP-37: Developer Approval as a Protected Predicate
In this configuration, a developer or authorized operator provides an
approval artifact corresponding to the Candidate Self-Mutation Act;
Under this condition, the Protected Enforcement Domain validates the
approval artifact against the proposed policy transition; and
Under this condition, the approval artifact does not independently
activate the proposed modification without successful protected
validation and capability verification at the mutation-activation
Finality Sink.
13.38. EP-38: Runtime Revocation and Mutation Revalidation
In this configuration, a change in a required policy epoch,
revocation state, mutation scope, or protected authority condition
causes a previously proposed but not yet activated mutation to be
denied or revalidated before effectuation;
Das Expires 19 April 2027 [Page 1046]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, a stale Self-Modification Capability cannot
authorize activation under an incompatible current policy state.
13.39. EP-39: Protected Sub-Agent Delegation Finality System
An implementation for controlling delegation of execution authority
between artificial-intelligence agents, uses the following components
and conditions:
a primary artificial-intelligence agent configured to generate a
proposed delegation to a subordinate agent, specialist agent, coding
agent, retrieval agent, tool agent, scheduling agent, security agent,
or external automated service;
a delegation interception component configured to represent the
proposed delegation as a Candidate Delegation Act maintained in a
Non-Effective State;
a Delegation Authority Object identifying at least a parent-agent
identity, a proposed delegated-agent identity, a delegated objective,
a permitted authority scope, and an applicable delegation boundary;
a Protected Enforcement Domain isolated from authority controlled by
the primary artificial-intelligence agent, configured to:
validate the Candidate Delegation Act against the Delegation
Authority Object;
evaluate a permitted subtask class, tool class, data scope, memory
scope, time window, recursion limit, execution budget, and prohibited
operation class, where applicable;
validate applicable policy epoch, revocation state, and nonce
conditions;
generate or commit protected delegation-validation evidence; and
release a scoped Delegation Capability upon successful validation;
a delegation-acceptance Finality Sink configured to verify the
Delegation Capability before admitting the proposed delegation into
an executable state; and
Under this condition, the primary agent cannot confer executable
delegated authority merely by spawning the subordinate agent,
transferring an instruction, assigning a task, or communicating a
proposed authority scope.
Das Expires 19 April 2027 [Page 1047]
Internet-Draft Protected AI Execution Finality October 2026
13.40. EP-40: Child-Agent Scope Restriction
In this configuration, the Delegation Capability identifies a
permitted objective, permitted tool class, permitted data scope,
permitted memory scope, permitted time window, or permitted execution
budget;
Under this condition, the subordinate agent is prevented from
receiving delegated authority exceeding the validated scope.
13.41. EP-41: Recursive Delegation Control
In this configuration, a subordinate agent proposes a further
delegation;
Under this condition, the further delegation is represented as an
additional Candidate Delegation Act; and
Under this condition, the Protected Enforcement Domain validates the
further delegation against the applicable parent authority, remaining
delegation scope, recursion constraint, and current protected
authorization state.
13.42. EP-42: Separation of Delegation from Downstream Effectuation
In this configuration, validation of the Delegation Capability
permits a bounded delegation but does not independently authorize an
externally effective tool invocation, file mutation, network
transmission, credential release, payment, or other consequential
operation;
Under this condition, each such governed downstream operation remains
subject to its applicable protected execution-finality validation and
Finality Sink verification.
13.43. EP-43: Protected Autonomous Code-Deployment Finality System
An implementation for governing deployment of code or infrastructure
modifications proposed by an artificial-intelligence agent, uses the
following components and conditions:
an autonomous coding or software-development execution environment
configured to generate a code modification, dependency modification,
build-script modification, package modification, infrastructure
configuration, or deployment instruction;
Das Expires 19 April 2027 [Page 1048]
Internet-Draft Protected AI Execution Finality October 2026
a deployment interception component configured to intercept a
proposed consequential modification before at least one of repository
merge, artifact signing, package publication, production deployment,
or infrastructure activation;
a Candidate Deployment Act Descriptor identifying a repository,
commit or change digest, modification class, affected artifact,
deployment target, and release-finality boundary;
a Protected Enforcement Domain configured to:
validate the Candidate Deployment Act against an applicable Supply-
Chain Authority Object;
evaluate authorized development purpose, approved workflow, changed-
file scope, dependency changes, credential-handling changes,
privileged operations, network-egress changes, test results, scan
results, review state, and environment restrictions, where
applicable;
generate or commit a Deployment LAVR or ZK-LAVR corresponding to
successful protected validation; and
release a Scoped Release Capability bound to the validated deployment
act, artifact, target environment, policy epoch, nonce, and
applicable release Finality Sink;
a release Finality Sink associated with a repository manager, merge
controller, artifact signer, package registry, build system,
deployment orchestrator, or infrastructure controller, configured to
verify the Scoped Release Capability before completing the governed
release operation; and
Under this condition, the release Finality Sink refuses effectuation
of the Candidate Deployment Act if the Scoped Release Capability
fails verification.
13.44. EP-44: Artifact and Commit Binding
In this configuration, the Scoped Release Capability is bound to a
commit digest, artifact digest, repository identity, branch identity,
deployment target, release environment, policy epoch, nonce, and
expiry;
Under this condition, substitution of an unapproved artifact or
deployment target causes the release Finality Sink to refuse the
operation.
Das Expires 19 April 2027 [Page 1049]
Internet-Draft Protected AI Execution Finality October 2026
13.45. EP-45: Protected Signing or Publication Key
In this configuration, a production signing key, package-publication
key, artifact-activation key, or deployment-enablement key is
retained in a protected hardware security module or secure enclave;
Under this condition, the protected key cannot be used for the
governed release operation unless a valid corresponding Scoped
Release Capability is verified.
13.46. EP-46: Agent-Generated Skill Deployment
In this configuration, the Candidate Deployment Act comprises
installation, activation, publication, or execution enablement of an
agent-generated skill, plug-in, tool package, or executable artifact;
Under this condition, the Protected Enforcement Domain validates the
proposed skill or artifact against its authorized purpose, approved
tool graph, dependency changes, privileged API use, and permitted
execution scope.
13.47. EP-47: Staged Deployment and Drift Interruption
In this configuration, a deployment comprises a plurality of release
stages, canary stages, progressive rollout stages, or deployment
environments;
Under this condition, the Protected Enforcement Domain generates
stage-associated validation evidence and releases a corresponding
scoped rollout capability for an authorized stage; and
Under this condition, detected runtime drift, policy-state
invalidity, or revocation prevents issuance of a subsequent rollout
capability, thereby preventing further deployment progression.
13.48. EP-48: Protected Cross-Domain AI-Fabric Transfer Finality System
A computer-implemented hardware-assisted system for controlling
transfer of artificial-intelligence computation state between
protected execution domains, uses the following components and
conditions:
a plurality of compute, accelerator, memory, or network-fabric
domains configured to exchange at least one of model parameters,
tensors, key-value cache data, gradients, activations, embeddings,
inference context, checkpoint state, or other artificial-intelligence
computation data;
Das Expires 19 April 2027 [Page 1050]
Internet-Draft Protected AI Execution Finality October 2026
a fabric-transfer interception component associated with a network
interface controller, SmartNIC, data processing unit, accelerator
interconnect, fabric switch, memory-fabric gateway, optical
interconnect controller, or accelerator-management component;
the fabric-transfer interception component being configured to
intercept a proposed cross-domain transfer before protected
computation data crosses an applicable fabric-finality boundary and
to represent the proposed transfer as a Candidate Fabric Transfer Act
maintained in a Non-Effective State;
a Candidate Fabric Transfer Act Descriptor identifying a source
compute domain, a destination compute domain, a class of computation
data, a transfer operation, and an applicable fabric-finality
boundary;
a Protected Enforcement Domain configured to:
validate the Candidate Fabric Transfer Act against a Cross-Domain
Fabric Authorization Object;
verify applicable source-domain authority, destination-domain
authority, transfer-data classification, approved workload graph,
fabric route, runtime transfer envelope, and policy state;
generate or commit a Fabric Transfer LAVR or ZK-LAVR corresponding to
the protected validation; and
release a scoped Fabric Transfer Capability upon successful
validation;
a fabric Finality Sink implemented at or adjacent to an admission
queue, fabric lane, switch pipeline, DMA interface, accelerator
memory-access interface, network-forwarding interface, or cross-
domain delivery boundary;
Under this condition, the fabric Finality Sink independently verifies
the Fabric Transfer Capability before admitting, routing, switching,
replicating, transferring, or delivering the protected computation
data; and
Under this condition, the fabric Finality Sink remains closed to the
governed transfer when the required Fabric Transfer Capability is
absent, invalid, revoked, expired, replayed, or inconsistent with the
Candidate Fabric Transfer Act.
Das Expires 19 April 2027 [Page 1051]
Internet-Draft Protected AI Execution Finality October 2026
13.49. EP-49: Fabric Transfer Descriptor Granularity
In this configuration, the Candidate Fabric Transfer Act Descriptor
further includes one or more of a source accelerator measurement,
destination accelerator measurement, workload identity, tenant
identity, model identity, tensor class, memory region, transfer size,
collective-operation type, fabric route, switch identity,
jurisdiction, policy epoch, nonce, expiry, and fabric Finality Sink
identity.
13.50. EP-50: Hardware-Latched Transfer Admission
In this configuration, a fabric lane, switch admission entry, DMA
queue, optical path, memory-access interface, or accelerator transfer
interface is maintained in a hardware-disabled or non-admitting
state;
Under this condition, successful verification of the Fabric Transfer
Capability enables the corresponding bounded transfer through the
hardware-controlled interface.
13.51. EP-51: Continuous Tensor or Memory-Transfer Validation
In this configuration, the protected computation data comprises a
stream divided into packets, transfer blocks, tensor slices, memory
pages, collective-operation phases, or transfer windows;
Under this condition, a protected validation receipt or rolling
Fabric Transfer Capability is associated with a corresponding
transfer unit or window; and
Under this condition, detection of route drift, unauthorized
destination change, transfer-size anomaly, or deviation from an
approved workload graph causes subsequent transfer units to be
withheld.
13.52. EP-52: Hardware-Freshness Binding
In this configuration, the Fabric Transfer Capability is bound to a
hardware-freshness value derived from one or more of an accelerator
counter, fabric sequence number, secure switch state, trusted clock,
secure monotonic counter, boot epoch, or protected device state;
Under this condition, replay of a previously valid transfer
capability outside its authorized freshness context fails
verification.
Das Expires 19 April 2027 [Page 1052]
Internet-Draft Protected AI Execution Finality October 2026
13.53. EP-53: Separated Cold-Path Validation and Line-Rate Finality
In this configuration, the Protected Enforcement Domain performs a
comparatively higher-cost authority-validation operation outside a
latency-sensitive transfer path;
Under this condition, the fabric Finality Sink performs bounded-time
local capability verification using a protected hardware lookup
entry, sequence counter, short-lived authentication tag, route grant,
DMA descriptor, queue-pair capability, or equivalent transfer-
admission record;
and in which the local verification remains mandatory before the
governed transfer is admitted.
13.54. EP-54: Protected Pre-Computation Model Admission System
An implementation for controlling admission of an artificial-
intelligence computation request to a model-execution environment,
uses the following components and conditions:
a request-admission component positioned between a requesting client,
artificial-intelligence agent, or application and a model-execution
service;
the request-admission component being configured to receive a
proposed inference request, agent request, tool-enabled computation
request, retrieval-enabled computation request, memory-enabled
computation request, or other governed computation request;
a governed computation-context descriptor representing the proposed
computation request and identifying at least a requested model or
model class, an applicable execution purpose, a proposed workflow or
policy context, and a protected computation-admission boundary;
a Protected Governance Domain configured to evaluate whether the
governed computation-context descriptor satisfies an Approved
Algorithmic Logic Fingerprint Condition;
a computation-start authorization artifact generated or validated
through the Protected Governance Domain and bound to the governed
computation-context descriptor and Approved Algorithmic Logic
Fingerprint Condition;
Under this condition, the request-admission component retains the
proposed computation request in a pending admission state until
successful verification of the computation-start authorization
artifact;
Das Expires 19 April 2027 [Page 1053]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, the request-admission component refuses
forwarding or execution admission when the computation-start
authorization artifact is absent, invalid, expired, revoked,
replayed, or inconsistent with the governed computation context; and
Under this condition, authentication of the requesting client or
possession of an application programming interface credential does
not independently substitute for the required computation-start
authorization artifact.
13.55. EP-55: Model and Workflow Measurement Binding
In this configuration, the computation-start authorization artifact
is bound to at least one of a model identifier, checkpoint hash,
adapter digest, approved workflow class, tool-policy reference,
retrieval-policy reference, memory-policy reference, safety-policy
reference, purpose class, jurisdiction condition, tenant identity,
destination context, policy epoch, or nonce.
13.56. EP-56: Protected Model-Loader Admission
In this configuration, the request-admission component is associated
with a model loader, model registry, accelerator-runtime initializer,
checkpoint loader, or adapter loader;
Under this condition, model weights, adapters, execution state, or
accelerator-resident model state are not activated for the governed
computation until the computation-start authorization artifact
verifies against the approved model state.
13.57. EP-57: Separate Downstream Execution Authority
In this configuration, a protected execution-finality subsystem
configured to treat a tool invocation, external application
programming interface call, file operation, network transmission, or
other externally effective operation arising from an admitted
computation as a separate Candidate Act;
Under this condition, admission of the computation does not itself
confer authorization to effectuate the separate Candidate Act;
and in which the separate Candidate Act is subject to its own
protected validation, scoped execution-capability release, and
applicable Finality Sink verification.
Das Expires 19 April 2027 [Page 1054]
Internet-Draft Protected AI Execution Finality October 2026
13.58. EP-58: Protected Service-Mesh Effectuation System
An implementation for controlling externally effective operations
generated by a cloud-hosted artificial-intelligence workload, uses
the following components and conditions:
an artificial-intelligence workload executing in a container, pod,
virtual machine, serverless runtime, isolated process, or equivalent
cloud execution environment;
an infrastructure-level interception component comprising a service-
mesh proxy, sidecar proxy, ingress controller, egress controller,
application programming interface gateway, workload proxy, or network
policy enforcement point;
the infrastructure-level interception component being positioned to
intercept a proposed operation comprising an outbound request,
service-to-service call, application programming interface response,
message-bus write, database request, or downstream workflow
invocation before the proposed operation crosses a governed
execution-finality boundary;
a Protected Enforcement Domain configured to validate a Candidate Act
Descriptor associated with the proposed operation against an
applicable workload identity, service identity, intended destination,
network route, authorized behavioral-logic class, policy state, and
revocation state;
the Protected Enforcement Domain being further configured to generate
or commit protected validation evidence and release a scoped
Execution-Enabling Capability corresponding to the proposed
operation;
the infrastructure-level interception component comprising or
cooperating with a Finality Sink configured to verify the scoped
Execution-Enabling Capability against the proposed operation and
applicable source-workload and destination-service context; and
Under this condition, the Finality Sink refuses transmission,
forwarding, connection establishment, service invocation, or message
delivery when the scoped Execution-Enabling Capability fails
verification.
Das Expires 19 April 2027 [Page 1055]
Internet-Draft Protected AI Execution Finality October 2026
13.59. EP-59: Service Identity and Session Binding
In this configuration, the scoped Execution-Enabling Capability is
bound to one or more of a source workload identity, source container
identity, destination service identity, authorized network route,
mutually authenticated transport session, policy epoch, revocation
epoch, nonce, and protected validation-record digest.
13.60. EP-60: Service-Mesh Bypass Prevention
In this configuration, the cloud execution environment is configured
to prevent the governed artificial-intelligence workload from
transmitting a Candidate Act through an alternative direct network or
service interface that bypasses required Finality Sink capability
verification.
13.61. EP-61: Fail-Closed Route and Policy Mismatch
In this configuration, the Finality Sink refuses an operation upon
detecting an expired capability, revoked authority, unauthorized
service substitution, source-workload mismatch, destination mismatch,
replay condition, or route inconsistent with the bound execution
scope.
13.62. EP-62: Distributed Hardware-Watchdog Execution Interlock System
An implementation for governing consequential operations performed by
an artificial-intelligence execution environment, uses the following
components and conditions:
an artificial-intelligence execution domain configured to execute an
agent, model, agentic workflow, tool, or autonomous process;
an out-of-band monitoring domain isolated from execution authority
controlled by the artificial-intelligence execution domain, the out-
of-band monitoring domain comprising a protected processor, data
processing unit, secure controller, isolated accelerator, or
equivalent independent security component;
a monitoring-state generator configured to produce a protected
monitoring-state record representing a measured or evaluated
execution condition of the artificial-intelligence execution domain,
the monitoring-state record comprising a workload identity,
monitoring-state version, validity condition, and enforcement-state
indicator;
Das Expires 19 April 2027 [Page 1056]
Internet-Draft Protected AI Execution Finality October 2026
a Protected Enforcement Domain configured to receive the protected
monitoring-state record and determine whether a proposed externally
effective operation is authorized under an applicable monitoring-
state version and operation-specific authority state;
a plurality of independently enforceable Finality Sinks associated
with two or more effectuation classes selected from network
transmission, application programming interface dispatch, credential
application, persistent storage commitment, tool execution, payment
instruction, accelerator-state export, and device actuation;
a protected authorization mechanism configured to bind an execution-
enabling capability for a particular Candidate Act to the
corresponding monitoring-state version, Candidate Act Descriptor,
applicable Finality Sink, and protected authorization state;
Under this condition, each applicable Finality Sink independently
verifies the capability and the required monitoring-state condition
before effectuation, rather than treating a generic observation or
model-access permission as sufficient authorization; and
Under this condition, an invalid, stale, revoked, inconsistent, or
unavailable required monitoring-state condition causes the affected
Finality Sink to refuse effectuation through its governed boundary.
13.63. EP-63: Hardware-Attested Monitoring State
In this configuration, the protected monitoring-state record
comprises a cryptographically authenticated measurement or
attestation generated by the out-of-band monitoring domain;
Under this condition, the Protected Enforcement Domain validates the
authenticity, workload association, sequence or version value, and
freshness of the record before relying upon it for execution
authorization.
13.64. EP-64: Watchdog-to-Finality Revocation Fence
In this configuration, the out-of-band monitoring domain detects an
execution-policy violation, authority-scope deviation, unauthorized
tool activity, or runtime-behavior anomaly;
Under this condition, the detected condition causes advancement of a
protected revocation or monitoring-state version; and
Under this condition, each affected Finality Sink rejects an
execution-enabling capability bound to a superseded version before
permitting a new consequential operation.
Das Expires 19 April 2027 [Page 1057]
Internet-Draft Protected AI Execution Finality October 2026
13.65. EP-65: Prevention Despite Continued Model Access
In this configuration, authorization of further model inference is
controlled by a model-access interface independently of at least one
downstream Finality Sink;
Under this condition, a Candidate Act produced before a model-access
interruption remains subject to verification at the applicable
downstream Finality Sink; and
Under this condition, the downstream Finality Sink prevents
unauthorized effectuation notwithstanding successful earlier
inference or possession of previously generated model output.
13.66. EP-66: Monitoring Failure and Stale-State Handling
In this configuration, the Protected Enforcement Domain or Finality
Sink determines whether a required monitoring-state record is
unavailable, stale, inconsistent, or outside an authorized freshness
interval;
Under this condition, no new execution capability is accepted for a
protected consequential operation requiring that monitoring state
until a corresponding protected recovery or revalidation condition
succeeds.
13.67. EP-67: Quarantine with Effectuation-State Preservation
In this configuration, a quarantine command causes restriction of
further agent computation, tool invocation, or infrastructure access;
Under this condition, protected operation-state records distinguish
operations already confirmed effective from pending Candidate Acts
and operations having indeterminate completion status; and
Under this condition, pending consequential operations remain subject
to finality verification, and a quarantine event does not itself
authorize rollback, replay, duplicated effectuation, or completion of
an unverified operation.
13.68. EP-68: Model-Path and Effectuation-Path Dual Authorization
System
An implementation for controlling artificial-intelligence inference
and externally effective operations derived therefrom, uses the
following components and conditions:
Das Expires 19 April 2027 [Page 1058]
Internet-Draft Protected AI Execution Finality October 2026
a model-execution environment configured to receive a proposed
inference or agent-computation request;
a protected model-access gate positioned on a governed path to a
model-execution service, the protected model-access gate being
configured to verify a computation-admission authorization associated
with a requested model, workload, execution purpose, and approved
computation context;
an agent or tool execution environment configured to generate a
proposed externally effective operation from an admitted computation;
a protected operation-classification component configured to
represent the proposed externally effective operation as a Candidate
Act and maintain the Candidate Act in a Non-Effective State pending
execution authorization;
a Protected Enforcement Domain configured to validate an operation-
specific authorization context comprising at least a concrete
operation descriptor, applicable execution-authority state, protected
policy state, and intended effectuation boundary;
a protected evidence-commitment component configured to generate or
commit an operation-specific validation record before, or atomically
with, availability of an operation-specific execution capability;
a downstream Finality Sink separate in enforcement function from the
protected model-access gate, the downstream Finality Sink being
positioned at an interface through which the Candidate Act would
become externally effective and being configured to independently
verify the operation-specific execution capability before
effectuation;
Under this condition, successful model-access authorization does not
independently authorize effectuation of the Candidate Act;
Under this condition, revocation of model-access authorization
prevents further governed model computation but does not substitute
for verification of a previously generated Candidate Act at the
downstream Finality Sink; and
Under this condition, the Candidate Act remains non-effective through
the governed execution path unless the downstream Finality Sink
verifies the operation-specific execution capability against the
actual operation and current applicable authorization conditions.
Das Expires 19 April 2027 [Page 1059]
Internet-Draft Protected AI Execution Finality October 2026
13.69. EP-69: Inference-to-Act Context Binding
In this configuration, a protected computation-admission record
comprises a model identity, workload identity, approved execution
context, policy epoch, and authorization-state identifier;
Under this condition, the operation-specific authorization context
references or cryptographically binds the computation-admission
record to a downstream Candidate Act Descriptor without treating the
computation-admission record as sufficient execution authority.
13.70. EP-70: Streaming Output and Partial-Action Control
In this configuration, the artificial-intelligence execution
environment produces a sequence of model outputs, tool-call
fragments, decoded action representations, or partially generated
command structures;
Under this condition, an externally effective fragment or operation
derived from the sequence is withheld until the applicable downstream
Finality Sink verifies a capability bound to the corresponding
completed or bounded Candidate Act; and
Under this condition, interruption of future model inference does not
authorize release of an already buffered but unverified consequential
operation.
13.71. EP-71: Multi-Sink Effectuation Classification
In this configuration, a proposed agentic workflow comprises a
plurality of consequential operations having different effectuation
boundaries;
Under this condition, the protected operation-classification
component identifies the applicable Finality Sink for each
consequential operation; and
Under this condition, a capability authorizing one operation or
Finality Sink does not independently authorize effectuation of a
different operation at another Finality Sink.
13.72. EP-72: Remote Effectuation Verification
In this configuration, the downstream Finality Sink comprises a
receiving service, remote execution gateway, protected database-
commit interface, payment execution interface, hardware actuator, or
trusted connector;
Das Expires 19 April 2027 [Page 1060]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, the downstream Finality Sink reconstructs or
verifies the actual Candidate Act presented for effectuation against
the operation-specific execution capability and protected validation-
state commitment; and
Under this condition, the downstream Finality Sink refuses an
operation that differs from the authorized operation in an
effectuation-relevant parameter, including destination, recipient,
operation type, protected state version, or applicable execution
scope.
13.73. EP-73: Confidential Cloud AI-Agent Execution and Cryptographic
Finality
An implementation for governing externally effective operations
generated by an artificial-intelligence workload executing within a
confidential or virtualized cloud-computing environment, uses the
following components and conditions:
a protected or isolated virtual-machine execution environment
configured to execute an artificial-intelligence agent, agentic
workflow, model runtime, or tool-execution process;
an execution-context measurement component configured to obtain a
machine-verifiable measurement or attestation representing at least
one of a virtual-machine runtime state, approved software
configuration, model configuration, agent workflow, execution policy,
or protected workload identity;
a Candidate Act interception component configured to intercept a
proposed externally effective operation originating from the
artificial-intelligence workload and to maintain the proposed
operation in a Non-Effective State before crossing a governed cloud,
host, service, or network effectuation boundary;
a Protected Enforcement Domain isolated from execution authority
controlled by the artificial-intelligence workload, the Protected
Enforcement Domain being configured to:
obtain a Candidate Act Descriptor identifying the proposed operation
and its applicable effectuation boundary;
validate the execution-context measurement against an Approved
Algorithmic Logic Fingerprint Condition or applicable protected
runtime-authority condition;
Das Expires 19 April 2027 [Page 1061]
Internet-Draft Protected AI Execution Finality October 2026
validate the Candidate Act against an applicable authority object,
execution purpose, permitted operation scope, policy state,
revocation state, and freshness condition;
generate or commit protected validation evidence corresponding to the
Candidate Act; and
release a scoped, non-bearer execution capability bound to the
Candidate Act and applicable Finality Sink only upon successful
validation;
a Finality Sink associated with a virtual-machine egress interface,
host interface, service-mesh gateway, application programming
interface gateway, credential-release interface, storage-commit
interface, or network-transmission interface, configured to
independently verify the scoped execution capability against the
actual proposed operation and current applicable authorization state
before effectuation; and
Under this condition, successful confidential virtual-machine
attestation or execution within an isolated virtual machine does not
independently confer authority to perform the proposed externally
effective operation, and in which the Finality Sink refuses
effectuation when required execution-capability verification fails.
13.74. EP-74: Hardware-Rooted Composite ALF
In this configuration, the execution-context measurement comprises or
contributes to a Hardware-Rooted Composite Algorithmic Logic
Fingerprint identifying one or more of a model identifier, checkpoint
hash, adapter hash, tokenizer configuration, decoder configuration,
system-instruction policy, safety configuration, tool-permission
graph, retrieval-source graph, orchestration graph, virtual-machine
measurement, hardware attestation report, and policy epoch.
13.75. EP-75: Measured Workload Configuration
In this configuration, the Protected Enforcement Domain compares a
runtime-used model configuration, agent workflow, tool configuration,
or execution-policy state with a corresponding approved measurement
or fingerprint;
Under this condition, a mismatch causes the corresponding Candidate
Act to remain in the Non-Effective State despite successful
authentication of the virtual-machine execution environment.
Das Expires 19 April 2027 [Page 1062]
Internet-Draft Protected AI Execution Finality October 2026
13.76. EP-76: Privacy-Preserving Cryptographic Validation
In this configuration, the protected validation evidence comprises a
cryptographically authenticated validation receipt or zero-knowledge
validation receipt establishing satisfaction of applicable authority
and runtime-integrity predicates;
Under this condition, the Finality Sink verifies the protected
validation evidence and corresponding capability without requiring
disclosure of at least one protected internal policy, private user
attribute, proprietary model configuration, or confidential workflow
parameter.
13.77. EP-77: Cloud Tenant and Destination Scope
In this configuration, the Candidate Act Descriptor further
identifies a tenant context, cloud-workload identity, requesting
virtual-machine identity, destination service identity, destination
network context, and applicable policy epoch;
Under this condition, an execution capability associated with one
authorized tenant or destination context does not authorize a
different tenant or destination context.
13.78. EP-78: Virtual-Machine Snapshot Replay Resistance
In this configuration, a protected execution-capability consumption
state, nonce state, or hardware-freshness state is maintained outside
a rollback-accessible portion of the artificial-intelligence
workload;
Under this condition, restoration of a previously stored virtual-
machine snapshot does not restore authority to reuse a capability
previously consumed, revoked, or invalidated in the protected state.
13.79. EP-79: Confidential Governance VM and Hardware-Attested SmartNIC
Finality
An implementation for governing externally effective operations
generated within an artificial-intelligence compute infrastructure,
uses the following components and conditions:
at least one artificial-intelligence compute node configured to
generate a proposed external operation or transfer;
a governance compute node executing within a confidential virtual-
machine environment providing hardware-supported memory
confidentiality or integrity protection;
Das Expires 19 April 2027 [Page 1063]
Internet-Draft Protected AI Execution Finality October 2026
a hardware-rooted attestation component associated with the
governance compute node and configured to produce an authenticated
attestation record identifying a governance workload measurement and
a protected execution configuration;
a Protected Enforcement Domain configured to verify the authenticated
attestation record against an approved hardware trust root,
registered governance identity, and applicable protected policy
state;
an execution-authorization component configured to validate a
Candidate Act associated with the proposed external operation and
release an operation-scoped execution capability dependent upon
successful protected authorization and an acceptable governance-node
attestation state;
an authenticated fabric-management communication path configured to
transfer the execution capability from the governance compute node or
protected authority component toward an effectuation controller;
a hardware-enforced Finality Sink implemented in or associated with a
SmartNIC, data processing unit, rack-boundary network controller,
accelerator-egress interface, or protected network-forwarding
component;
Under this condition, the hardware-enforced Finality Sink verifies
the execution capability against the Candidate Act, authorized
effectuation boundary, and registered attestation state of the
issuing governance component before enabling external transmission;
and
Under this condition, invalidation of the required governance-node
attestation state or failure of capability verification prevents the
proposed operation from crossing the governed hardware-enforced
effectuation boundary.
13.80. EP-80: Confidential VM Attestation Object
In this configuration, the authenticated attestation record comprises
a Hardware Finality Gate Attestation Object including one or more of
a governance firmware digest, confidential virtual-machine policy
version, launch measurement, host-data field, hardware signing
evidence, and protected device identity;
Under this condition, the Protected Enforcement Domain verifies the
attestation object against an applicable hardware-vendor certificate
chain or registered public-key trust root.
Das Expires 19 April 2027 [Page 1064]
Internet-Draft Protected AI Execution Finality October 2026
13.81. EP-81: Confidential Governance-Key Isolation
In this configuration, cryptographic key material used for protected
governance or capability issuance is maintained within a protected
governance boundary inaccessible to an ordinary artificial-
intelligence compute process;
Under this condition, the compute node communicates with the
governance component through an authenticated interface rather than
obtaining unrestricted access to the protected governance key
material.
13.82. EP-82: Attestation Change Disables Capability Issuance
In this configuration, a change to a required governance-node
firmware measurement, confidential virtual-machine launch
measurement, policy version, or protected software configuration
results in an attestation state that no longer satisfies an approved
governance-node measurement condition;
Under this condition, the Protected Enforcement Domain refuses
further execution-capability issuance dependent upon that governance
node until successful revalidation.
13.83. EP-83: Cryptographically Bound Hardware Freshness
In this configuration, the execution capability is additionally bound
to a hardware-freshness state comprising at least one of a trusted
monotonic counter, secure boot epoch, protected clock, device
sequence value, or hardware-attested nonce;
Under this condition, restoration or replay of previously valid
authorization material fails when the current hardware-freshness
state no longer corresponds to the capability.
13.84. EP-84: User-Controlled Confidential VM with Cryptographically
Bound Execution Authority
An implementation for operating an artificial-intelligence agent
within a confidential virtual-machine environment under separate
confidentiality and execution-authority controls, uses the following
components and conditions:
a cloud-hosted confidential virtual-machine environment configured to
execute an artificial-intelligence agent and maintain protected user
data, agent memory, connected-service data, or task state;
Das Expires 19 April 2027 [Page 1065]
Internet-Draft Protected AI Execution Finality October 2026
a cryptographic data-protection component configured to protect at
least a portion of the protected user data using encryption
associated with user-controlled or user-authorized key material;
a hardware-rooted attestation component configured to generate a
cryptographically verifiable measurement of the confidential virtual-
machine environment, including an applicable software measurement and
security-configuration state;
a protected key-enablement component configured to condition
availability of a decryption-enabling secret, derived data-access
key, or bounded cryptographic data-access operation upon verification
of the attestation measurement and a corresponding user-authorized
data-access scope;
an artificial-intelligence execution environment configured to
prepare a proposed externally effective operation using data made
available under the authorized data-access scope;
a Protected Enforcement Domain configured to classify the proposed
externally effective operation as a Candidate Act maintained in a
Non-Effective State and to validate the Candidate Act against an
operation-specific authority object, execution context, current
policy state, protected freshness state, and intended effectuation
boundary;
a protected evidence-commitment component configured to commit
validation evidence corresponding to the Candidate Act before, or
atomically with, release of an operation-specific execution
capability;
a Finality Sink configured to independently verify the operation-
specific execution capability before permitting an external
transmission, credential-mediated operation, file export, persistent-
state modification, or other consequential effect; and
Under this condition, successful cryptographic data decryption or
access within the confidential virtual machine does not independently
confer permission to effectuate the Candidate Act, and in which an
applicable failure of either a required data-access authorization
condition or execution-finality condition results in withholding of
the corresponding protected operation.
13.85. EP-85: User-Held Root-Key and Attested Derived-Key Release
In this configuration, a root encryption key remains under control of
a user or user-authorized external key authority;
Das Expires 19 April 2027 [Page 1066]
Internet-Draft Protected AI Execution Finality October 2026
Under this condition, a derived, wrapped, or session-limited key is
made available only to a confidential virtual-machine environment
satisfying a required remote-attestation predicate;
Under this condition, the derived, wrapped, or session-limited key is
restricted to a defined user-data scope, workload identity, validity
interval, or protected authorization state without requiring
disclosure of the root encryption key to the artificial-intelligence
agent.
13.86. EP-86: Dual Authorization for Decryption and External Effect
In this configuration, an authorization for protected data decryption
and an authorization for a consequential external operation are
represented by distinct cryptographic or protected-state conditions;
Under this condition, satisfaction of a decryption authorization
condition permits bounded access to protected data but does not
itself cause issuance of an externally effective operation
capability;
and in which the Finality Sink verifies the operation-specific
execution capability independently of the successful decryption
condition.
13.87. EP-87: Cryptographic Binding of Confidential-VM State to
Candidate Act
In this configuration, the operation-specific execution capability is
cryptographically bound to a canonical Candidate Act Descriptor, an
attested confidential virtual-machine measurement, a user-authorized
execution scope, a policy epoch, a nonce, and a Finality Sink
identity;
Under this condition, modification of an effectuation-relevant
parameter or required attested state after authorization causes the
capability to fail verification.
13.88. EP-88: Privacy-Preserving Execution Evidence
In this configuration, a cryptographically authenticated execution
record establishes that a specified Candidate Act underwent protected
authority validation and applicable Finality Sink verification;
Under this condition, the execution record is configured to permit
verification of the required enforcement condition without disclosing
the plaintext of the protected user data, reusable credential
material, or a user-controlled root encryption key.
Das Expires 19 April 2027 [Page 1067]
Internet-Draft Protected AI Execution Finality October 2026
13.89. EP-89: Confidential-VM Recovery and Key-State Continuity
In this configuration, restoration of an encrypted virtual-machine
backup, protected agent-memory snapshot, or recovered confidential
virtual-machine instance requires re-establishment of an authorized
attested execution context;
Under this condition, a protected execution-capability consumption or
revocation state is reconciled independently of rollback-accessible
backup contents;
and in which restoration of the confidential virtual machine does not
restore an expired, previously consumed, or revoked execution
capability.
13.90. EP-90: Portable Cloud-VM Agent Authority and Hardware
Effectuation System
An implementation for enforcing operation-specific execution
authority across multiple cloud or virtualized artificial-
intelligence execution substrates, uses the following components and
conditions:
an agent-execution control plane configured to deploy or manage an
artificial-intelligence agent in at least one execution substrate
selected from a container runtime, virtual machine, confidential
virtual machine, Kubernetes workload, on-premises compute host,
hybrid-cloud compute environment, or accelerator-backed agent
runtime;
a workload identity and measurement component configured to establish
an authenticated workload identity and an execution-context
measurement corresponding to a deployed instance of the artificial-
intelligence agent;
a Protected Enforcement Domain configured to maintain an
authorization-state version and one or more execution-policy
predicates applicable to the authenticated workload identity;
an operation-interception component configured to represent a
proposed externally effective operation generated by the deployed
instance as a Candidate Act maintained in a Non-Effective State;
a protected authorization component configured to validate the
Candidate Act against its operation descriptor, authenticated
workload identity, execution-context measurement, current protected
policy state, and designated effectuation boundary;
Das Expires 19 April 2027 [Page 1068]
Internet-Draft Protected AI Execution Finality October 2026
a cryptographic capability-issuance component configured to generate
or release a scoped execution capability bound to the Candidate Act,
authenticated workload identity, authorization-state version, and
designated Finality Sink;
a Finality Sink implemented in a host execution controller, virtual-
machine boundary, cloud network gateway, service-mesh component,
protected connector, SmartNIC, data processing unit, or accelerator-
egress controller;
Under this condition, the Finality Sink independently verifies the
scoped execution capability before allowing the proposed operation to
become externally effective; and
Under this condition, deployment of the artificial-intelligence agent
to a different execution substrate, reinstantiation of the workload,
or restoration of a previously authorized execution context does not
independently restore authority to execute an operation under a stale
or incompatible authorization-state version.
13.91. EP-91: VM and Container Identity Attestation
In this configuration, the workload identity and measurement
component validates a workload image digest, virtual-machine launch
measurement, container image identifier, agent runtime identity,
approved tool-policy digest, model configuration digest, or protected
execution-policy state;
Under this condition, an execution capability is rejected when its
workload identity or required measurement does not correspond to the
workload executing the Candidate Act.
13.92. EP-92: Runtime Policy Changes Across Cloud Replicas
In this configuration, the agent-execution control plane manages a
plurality of replicas, restarted workloads, virtual-machine
instances, or agent-execution nodes;
Under this condition, a protected policy-state transition advances
the authorization-state version applicable to a defined workload
scope;
Under this condition, each affected Finality Sink rejects a
capability bound to an incompatible prior authorization-state version
before admitting a subsequent consequential operation.
Das Expires 19 April 2027 [Page 1069]
Internet-Draft Protected AI Execution Finality October 2026
13.93. EP-93: Hardware-Supervised Cloud Egress
In this configuration, the designated Finality Sink is implemented in
a data processing unit, SmartNIC, protected network gateway, or
hardware-assisted cloud egress controller;
Under this condition, the Finality Sink verifies the capability and
the authenticated workload context without treating successful cloud-
network authentication or ordinary virtual-machine connectivity as
sufficient operation-specific execution authority.
13.94. EP-94: Cross-Runtime Migration and Snapshot Protection
In this configuration, a virtual-machine migration, container
replacement, workload rescheduling, checkpoint restoration, or cloud-
region failover results in a changed workload identity, execution-
context measurement, or protected deployment epoch;
Under this condition, a pending Candidate Act is revalidated against
the changed context before effectuation;
and in which the protected system prevents reuse of a previously
consumed capability or unauthorized duplication of an externally
effective operation following the runtime transition.
13.95. EP-95: Model-Path Authorization Does Not Replace Effectuation
Authorization
In this configuration, a model-access control component configured to
govern requests to a local or remote artificial-intelligence model;
Under this condition, successful model-access authorization permits
only the corresponding approved computation and does not
independently authorize a consequential operation generated by the
model;
Under this condition, an operation-specific capability is separately
required and independently verified at a downstream Finality Sink
before an externally effective operation is completed;
and in which interruption, quarantine, or revocation of future model-
access authority does not permit release of a previously generated
but unverified consequential operation.
14. Security Considerations
Das Expires 19 April 2027 [Page 1070]
Internet-Draft Protected AI Execution Finality October 2026
14.1. Threat Model and Enforcement Coverage
The requesting AI agent, untrusted tool output, subordinate
processes, and other compute-plane components are not assumed to
possess execution authority. Implementations need to identify the
actual privileged attackers and trusted computing base, including any
kernel, hypervisor, protected authority, credential broker, and
effectuation component. A Finality Gate is not non-bypassable merely
because a proxy is configured: every accessible path capable of
producing the specified governed effect must be blocked or subjected
to the required Finality Sink checks. Protection is limited to the
effectuation paths covered by the implemented enforcement mechanisms.
14.2. Canonicalization and Operation Substitution
When authorization depends upon executable identity, destinations,
HTTP methods, paths, parameters, request bodies, recipients, or other
operation attributes, the authority component and Finality Sink need
a consistent representation of those attributes. Ambiguous parsing,
mutable buffers, filesystem races, redirects, DNS rebinding,
connection reuse, and mismatched request normalization can cause the
actual operation to differ from the authorized operation. A
transport-layer enforcement mechanism cannot inspect encrypted
application-layer fields without an appropriate trusted application-
layer interface or decryption arrangement. Where a mandatory
attribute cannot be established, the operation is withheld.
14.3. Capability Protection and Context Binding
Capability authenticity by itself does not establish non-bearer
authorization. Implementations claiming context-bound or single-use
operation require enforcement of the specified Candidate Act, scope,
requester, sink, policy epoch, nonce, expiry, and usage bindings as
applicable. Signing or MAC keys and protected capability tables must
be shielded from unilateral agent modification. Capability replay,
substitution, cross-sink use, unauthorized delegation, and exposure
of credential material are relevant attack classes.
14.4. Protected State, Revocation, and Fail-Closed Behavior
Protected authorization-state changes, receipt commitments, quota or
nonce consumption, and capability release require the consistency
specified by the particular implementation. Concurrent attempts must
not exceed authorized usage. Required revocation or policy-epoch
checks must not silently fail open when state is stale, unavailable,
inconsistent, or rolled back. Restart, migration, snapshot
restoration, and recovery must not restore previously consumed or
revoked authority. Separately authorized safe or recovery actions do
Das Expires 19 April 2027 [Page 1071]
Internet-Draft Protected AI Execution Finality October 2026
not imply unrestricted permission for the original Candidate Act.
14.5. Credential and Delegation Boundaries
Credential isolation and operation authorization are different
properties. A host-side credential broker can keep underlying
secrets away from an AI agent yet still require an act-specific
verification before the broker uses the credential. Delegation of a
task to another agent does not automatically authorize every
consequential action generated by the subordinate component.
Implementations must define which operations and downstream
boundaries are separately governed.
14.6. Monitoring Versus Prevention
Out-of-band monitoring, anomaly detection, audit evidence, and
quarantine may aid detection and containment but do not, by
themselves, establish that a previously executed operation was
prevented. Interruption of future model inference likewise does not
necessarily stop a previously queued tool request. Where the desired
security guarantee is prevention, the relevant effectuation boundary
must withhold the effect until all mandatory authorization conditions
succeed.
14.7. Remote Completion and Recovery Limits
Local protected authorization-state atomicity does not guarantee
exactly-once completion at an unrelated remote service. A timeout
after a request may have been delivered leaves the external outcome
uncertain. Retrying must respect protected operation identity,
consumption state, and, when available, authenticated receiving-side
status, idempotency identifiers, or separate downstream verification.
The implementation must not report external completion merely because
a source-side gateway transmitted a request.
14.8. Operational Assurance and Testing
Testing should include missing or forged capabilities, stale policy
and revocation epochs, changed destinations or request bodies,
redirected requests, alternate egress paths, concurrent single-use
operations, crashes before or after evidence commitment, snapshot
rollback, failure of credential brokers, hardware freshness
mismatches, and indeterminate remote completion. Assurance claims
require implementation-specific review of the actual mediation
coverage and protection boundaries. The workflows in this document
propose illustrative negative tests; they are not evidence that an
implementation has passed them.
Das Expires 19 April 2027 [Page 1072]
Internet-Draft Protected AI Execution Finality October 2026
15. Relationship to Existing Standards
CBOR supplies a possible deterministic data representation, subject
to the additional encoding and application-profile rules needed for
an interoperable Candidate Act Descriptor; this document does not
require CBOR. See [RFC8949]
COSE supplies established structures for cryptographic authentication
of objects; this document does not select a concrete COSE profile or
impose one on the proposed capability representations. See [RFC9052]
Remote attestation can provide evidence concerning the protected
execution environment, but successful attestation is not equivalent
to authorization of a particular downstream consequential operation.
See [RFC9334]
OAuth Rich Authorization Requests illustrate established fine-grained
authorization input; the authority over a final consequential
operation must still be evaluated at its governed effectuation
boundary when this architecture requires it. See [RFC9396]
16. IANA Considerations
This document requests no IANA actions.
17. References
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, 2023,
<https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396, 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
Author's Address
Das Expires 19 April 2027 [Page 1073]
Internet-Draft Protected AI Execution Finality October 2026
Sangam Das
Independent Inventor
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 19 April 2027 [Page 1074]