Network Working Group S. Das Internet-Draft Independent Inventor and Researcher Intended status: Informational 7 September 2026 Expires: 11 March 2027 Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure draft-das-rats-attestation-bnd-execution-finality-02 Abstract Remote attestation can establish evidence about the hardware, firmware, software, configuration, and execution environment associated with a workload. In heterogeneous confidential-computing environments, this trust assessment can extend across CPUs, confidential virtual machines, GPUs, AI accelerators, DPUs, SmartNICs, and other trusted execution components. As AI training and inference workloads scale onto large fleets of GPUs and other accelerators, and as confidential-computing modes for those accelerators reach production deployment, the boundary between "the environment is trustworthy" and "this specific operation may proceed" becomes an increasingly consequential, and increasingly load-bearing, engineering question. An increasingly important class of workloads, however, does not merely compute data. AI agents and autonomous workloads can generate consequential operations such as API invocations, storage mutations, network configuration changes, infrastructure-control commands, financial instructions, device operations, and cross-workload requests. These operations are typically issued from, or on behalf of, GPU- and accelerator-hosted workloads, so the architecture is directly relevant to any infrastructure operator or hardware, DPU, SmartNIC, or confidential-computing vendor whose platform participates in generating, attesting, or effectuating such operations. This document is intended to be of particular interest to organizations building or operating large-scale confidential AI accelerator infrastructure, including GPU vendors, cloud and hyperscale operators, DPU and SmartNIC vendors, and confidential- computing platform providers, since the accompanying reference implementation and FAQ discussion (Section 34.8, Appendix C) illustrate the architecture using publicly documented attestation stacks such as NVIDIA's Confidential Computing and Attestation Suite (NRAS, RIM Service, and OCSP Service) alongside Intel Trust Domain Extensions (TDX) plus confidential-GPU composite attestation. These vendors and products are cited only as concrete, checkable, publicly Das Expires 11 March 2027 [Page 1] Internet-Draft Attestation-Bound Execution Finality September 2026 documented examples of the class of infrastructure the architecture addresses; this document is vendor-neutral, does not depend on any specific vendor's hardware or software, and neither claims nor implies review, adoption, endorsement, or affiliation by NVIDIA, Intel, or any other named vendor. An acceptable Attestation Result supplies trust information to a Relying Party; it is not, without an application-defined authorization step, a decision on the admissibility of each operation later emitted by the attested workload. This document describes an attestation-bound execution-finality architecture in which a consequential operation first exists as a Candidate Act in a non-effective state. Before that act can acquire external effect, its relevant parameters are cryptographically bound to validation context that can include Attestation Results, workload identity, execution context, policy, authorization scope, freshness information, and other application-specific evidence. A designated Finality Sink verifies the required binding at or before the boundary at which the Candidate Act would first acquire external effect. The resulting separation is between appraisal of the execution environment and authorization of a concrete operation at its effectuation boundary. The architecture is intended to complement, rather than replace, Remote ATtestation procedureS (RATS), Entity Attestation Token (EAT) [RFC9711], workload-identity systems, confidential computing, Trusted Execution Environments (TEEs), accelerator attestation, and existing authorization mechanisms. 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." Das Expires 11 March 2027 [Page 2] Internet-Draft Attestation-Bound Execution Finality September 2026 This Internet-Draft will expire on 11 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. From Computational Trust to Consequential Authority . . . 9 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Replacing RATS . . . . . . . . . . . . . . . . . . . . . 11 4.2. Declaring Attestation Insufficient . . . . . . . . . . . 11 4.3. Replacing OAuth or Workload Identity . . . . . . . . . . 11 4.4. Mandating Hardware . . . . . . . . . . . . . . . . . . . 11 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Candidate Act . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Non-Effective State . . . . . . . . . . . . . . . . . . . 12 5.3. Execution-Finality Validator . . . . . . . . . . . . . . 13 5.4. Protected Validation Evidence . . . . . . . . . . . . . . 14 5.5. Execution Handle . . . . . . . . . . . . . . . . . . . . 14 5.6. Finality Sink . . . . . . . . . . . . . . . . . . . . . . 15 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Binding Attestation to a Candidate Act . . . . . . . . . . . 17 8. Why Attestation Alone Is Not the Binding . . . . . . . . . . 18 9. Relationship to the RATS Architecture . . . . . . . . . . . . 20 10. Composite CPU and Confidential-Accelerator Environments . . . 21 11. AI Accelerator Example . . . . . . . . . . . . . . . . . . . 22 12. Hyperscale Deployment . . . . . . . . . . . . . . . . . . . . 23 13. DPU and SmartNIC Deployment . . . . . . . . . . . . . . . . . 25 14. Network Fabric Considerations . . . . . . . . . . . . . . . . 26 15. Relationship to Workload Identity . . . . . . . . . . . . . . 26 16. Separation of Identity, Trust, Authority, and Finality . . . 27 16.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 27 16.2. Trust . . . . . . . . . . . . . . . . . . . . . . . . . 27 16.3. Authority . . . . . . . . . . . . . . . . . . . . . . . 28 Das Expires 11 March 2027 [Page 3] Internet-Draft Attestation-Bound Execution Finality September 2026 16.4. Finality . . . . . . . . . . . . . . . . . . . . . . . . 28 17. Candidate Act Canonicalization . . . . . . . . . . . . . . . 28 18. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 29 19. Replay Resistance . . . . . . . . . . . . . . . . . . . . . . 29 20. Non-Bearer Properties . . . . . . . . . . . . . . . . . . . . 30 21. Finality Sink Placement . . . . . . . . . . . . . . . . . . . 31 22. Finality Sink Is Not Necessarily a New Appliance . . . . . . 31 23. Hot-Path and Cold-Path Processing . . . . . . . . . . . . . . 32 24. Legacy Deployment . . . . . . . . . . . . . . . . . . . . . . 33 25. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 34 25.1. Validation Failure . . . . . . . . . . . . . . . . . . . 34 25.2. Missing Attestation Context . . . . . . . . . . . . . . 34 25.3. Expired Validation Evidence . . . . . . . . . . . . . . 34 25.4. Parameter Mutation . . . . . . . . . . . . . . . . . . . 34 25.5. Finality Sink Unavailable . . . . . . . . . . . . . . . 34 26. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 35 27. Security Considerations . . . . . . . . . . . . . . . . . . . 35 28. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 29. Example: Confidential AI Inference in a Hyperscaler . . . . . 37 30. Example: DPU-Mediated AI Egress . . . . . . . . . . . . . . . 38 31. Example: Multi-Workload Agent Chain . . . . . . . . . . . . . 39 32. Interoperability Requirements . . . . . . . . . . . . . . . . 40 33. Potential Protocol Flow . . . . . . . . . . . . . . . . . . . 41 34. Minimal Vendor-Neutral Proof-of-Concept Profile . . . . . . . 42 34.1. Protected Operation . . . . . . . . . . . . . . . . . . 42 34.2. Canonical CandidateAct . . . . . . . . . . . . . . . . . 42 34.3. EAT and Attestation-Result Input . . . . . . . . . . . . 43 34.4. Signed Execution Handle . . . . . . . . . . . . . . . . 44 34.5. Finality-Sink Processing . . . . . . . . . . . . . . . . 44 34.6. Required Test Vectors . . . . . . . . . . . . . . . . . 45 34.7. Latency Measurement and Publication . . . . . . . . . . 46 34.8. Implementation Status . . . . . . . . . . . . . . . . . 47 Implemented Components . . . . . . . . . . . . . . . . . . . 47 Reference Security Flow . . . . . . . . . . . . . . . . . . . 48 Test Results . . . . . . . . . . . . . . . . . . . . . . . . 49 Measured Benchmarks . . . . . . . . . . . . . . . . . . . . . 49 Production Integration Boundaries . . . . . . . . . . . . . . 49 35. Why This Matters for AI Infrastructure . . . . . . . . . . . 50 36. Operational Considerations . . . . . . . . . . . . . . . . . 50 37. Discussion of Latency . . . . . . . . . . . . . . . . . . . . 51 38. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 51 39. Related Work by the Same Author . . . . . . . . . . . . . . . 52 40. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 41. Normative References . . . . . . . . . . . . . . . . . . . . 54 42. Informative References . . . . . . . . . . . . . . . . . . . 55 Appendix A. Architectural Summary . . . . . . . . . . . . . . . 58 Appendix B. Concise Statement for Discussion . . . . . . . . . . 59 Das Expires 11 March 2027 [Page 4] Internet-Draft Attestation-Bound Execution Finality September 2026 Appendix C. Technical FAQ and Anticipated Engineering Questions . . . . . . . . . . . . . . . . . . . . . . . . 59 FAQ 1. Isn't this already what a RATS Relying Party does? . . 60 FAQ 2. Is this simply AR4SI applied to individual requests? . 61 FAQ 3. How does this interact with composite CPU, CVM, GPU, and accelerator attestation? . . . . . . . . . . . . . . . 63 FAQ 4. Does this require changes to accelerator hardware or instruction sets? . . . . . . . . . . . . . . . . . . . 65 FAQ 5. Isn't WIMSE workload identity already enough to authorize the operation? . . . . . . . . . . . . . . . . . . . . 67 FAQ 6. Why isn't an OAuth access token or down-scoped transaction token sufficient? . . . . . . . . . . . . . 68 FAQ 7. Isn't the Execution Handle just another bearer token? . . . . . . . . . . . . . . . . . . . . . . . . 70 FAQ 8. Who creates the Candidate Act, and how is it canonicalized? . . . . . . . . . . . . . . . . . . . . 71 FAQ 9. What technically makes a Candidate Act "non-effective"? . . . . . . . . . . . . . . . . . . . 73 FAQ 10. How does the architecture prevent TOCTOU between authorization and execution? . . . . . . . . . . . . . 74 FAQ 11. How are replay, duplication, and retry handled at hyperscale? . . . . . . . . . . . . . . . . . . . . . . 76 FAQ 12. Would per-act verification destroy GPU or hyperscaler performance? . . . . . . . . . . . . . . . . . . . . . 77 FAQ 13. How does this work across multi-agent and multi-workload chains? . . . . . . . . . . . . . . . . . . . . . . . . 79 FAQ 14. How is this different from current WIMSE authorization-evidence/Permit work? . . . . . . . . . . 81 FAQ 15. How is this different from current RATS Action Evidence composition work? . . . . . . . . . . . . . . . . . . . 82 FAQ 16. Does every CUDA kernel invocation need an Execution Handle? . . . . . . . . . . . . . . . . . . . . . . . . 85 FAQ 17. What stops a compromised host from bypassing the Finality Sink? . . . . . . . . . . . . . . . . . . . . 86 FAQ 18. Could the Finality Sink or Execution-Finality Validator run inside GPU firmware, a DPU, SmartNIC, or a confidential VM? . . . . . . . . . . . . . . . . . . . . . . . . . . 87 FAQ 19. What if the Execution-Finality Validator itself is compromised? . . . . . . . . . . . . . . . . . . . . . 88 FAQ 20. Why use separate EAT-signing and Execution-Handle-signing keys? . . . . . . . . . . . . 88 FAQ 21. What happens with multiple Finality Sink replicas? . . 89 FAQ 22. How does this apply to streaming AI output and batched GPU operations? . . . . . . . . . . . . . . . . . . . . 90 FAQ 23. What happens if GPU state changes after attestation? . . . . . . . . . . . . . . . . . . . . . 90 FAQ 24. Why isn't normal API validation at the target enough? . . . . . . . . . . . . . . . . . . . . . . . . 91 Das Expires 11 March 2027 [Page 5] Internet-Draft Attestation-Bound Execution Finality September 2026 FAQ 25. Why is the reference implementation's protected effect stored in SQLite instead of executing a real GPU, cloud, or payment action? . . . . . . . . . . . . . . . . . . . . 91 FAQ 26. What would be required for a genuine NVIDIA or accelerator integration? . . . . . . . . . . . . . . . 92 Summary: Relationship Between RATS, WIMSE, and Execution Finality . . . . . . . . . . . . . . . . . . . . . . . 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95 1. Introduction Modern computing systems increasingly combine heterogeneous execution components. A single workload may involve: * a CPU; * a confidential virtual machine; * one or more GPUs or other AI accelerators; * a DPU or SmartNIC; * containerized or orchestrated workloads; * workload-identity credentials; * service-mesh components; * remote storage; * external APIs; * high-speed accelerator fabrics; * Ethernet or InfiniBand networks; and * cloud or hyperscale control-plane infrastructure. Remote attestation provides mechanisms through which claims about such environments can be appraised. The RATS architecture [RFC9334] defines Evidence, Verifiers, Attestation Results, and Relying Parties. A Relying Party can use Attestation Results when making application-specific decisions, including authorization decisions. Das Expires 11 March 2027 [Page 6] Internet-Draft Attestation-Bound Execution Finality September 2026 Composite attestation further permits trust assessments to incorporate multiple components of a heterogeneous confidential- computing environment. These mechanisms answer an important question: what properties can a relying party establish about the environment involved in computation? A distinct question becomes increasingly important as workloads become agentic: what causes one specific operation produced by that workload to become externally effective? Consider an attested AI workload that generates: POST /payment destination = account-B amount = 50000 currency = USD Figure 1 Attestation may establish important properties of the execution components. Whether the operation above is admissible remains an application-specific decision that can depend on its method, target, arguments, current policy, and resource state. The same observation applies to an AI workload generating: DELETE production-database Figure 2 or: modify_firewall(rule-X) Figure 3 or: deploy(image-Y, production) Figure 4 or: send(message-M, recipient-R) Das Expires 11 March 2027 [Page 7] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 5 or: open_valve(device-D, 80-percent) Figure 6 or: transfer_control(workload-A, workload-B) Figure 7 The environment may be fully attested and operating as expected. This document addresses a later transition: 1. computation of a proposed operation; and 2. acquisition of authority by that operation to produce an external consequence. This document calls the second transition execution finality. The architecture therefore separates: Computation | v Candidate Act | | non-effective v Validation / authorization binding | v Finality Sink | | effective v External Effect Figure 8 The design does not require a particular CPU, GPU, accelerator, TEE, cloud platform, network fabric, or authorization protocol. Das Expires 11 March 2027 [Page 8] Internet-Draft Attestation-Bound Execution Finality September 2026 2. Motivation 2.1. From Computational Trust to Consequential Authority Confidential computing and remote attestation provide increasingly strong mechanisms for establishing trust in the environments where workloads execute. AI workloads introduce a related but different problem. A model can generate outputs that are interpreted as commands. An AI inference result may become: * an RPC invocation; * an HTTP request; * a database mutation; * a network packet with control semantics; * a cloud-management request; * a payment instruction; * an industrial command; * an operating-system action; or * an instruction to another autonomous workload. The system therefore needs to distinguish an output that has merely been computed from an operation that has become authorized for consequence. This distinction is especially relevant where a workload may be: * probabilistic; * dynamically composed; * controlled by changing prompts or context; * invoking external tools; * processing untrusted input; Das Expires 11 March 2027 [Page 9] Internet-Draft Attestation-Bound Execution Finality September 2026 * operating across trust domains; or * acting autonomously after initial authorization. 3. Scope This document describes an architecture for binding a consequential Candidate Act to validation evidence before that act acquires external effect. The architecture applies to environments including, but not limited to: * confidential AI inference; * GPU and AI-accelerator workloads; * confidential virtual machines; * CPU-GPU composite trusted environments; * cloud and hyperscale AI infrastructure; * DPUs and SmartNICs; * workload-to-workload operations; * agentic AI systems; * service meshes; * API gateways; * storage systems; * cloud control planes; * network control planes; * distributed computing infrastructure; and * edge and device execution. Das Expires 11 March 2027 [Page 10] Internet-Draft Attestation-Bound Execution Finality September 2026 This is an architectural document, not a Candidate Act encoding or execution-authorization protocol. It neither changes RATS roles nor defines application policy, accelerator behavior, or transport operation. Validation may use hardware-protected or software enforcement, and the validating function may be colocated with or separated from the effectuation boundary. 4. Non-Goals The following are explicitly outside the scope of this architecture. 4.1. Replacing RATS This architecture does not redefine Evidence, Verifiers, Attestation Results, or the Relying Party model defined by RATS. Attestation Results can instead become inputs to execution-finality validation. 4.2. Declaring Attestation Insufficient This document does not assert that remote attestation is incomplete for its defined purpose. Rather, it addresses an additional lifecycle stage: binding relevant trust and authorization information to a concrete consequential operation. 4.3. Replacing OAuth or Workload Identity Existing identity and authorization mechanisms can provide inputs to the architecture. A workload credential, access token, workload identity, proof token, authorization detail, or other credential can form part of the validation context. 4.4. Mandating Hardware A deployment may use: * a TEE; * secure enclave; * HSM; * TPM-backed environment; Das Expires 11 March 2027 [Page 11] Internet-Draft Attestation-Bound Execution Finality September 2026 * confidential VM; * DPU; * SmartNIC; * kernel enforcement; * hypervisor; * trusted gateway; or * combinations of these mechanisms. The required property is enforcement of the non-effective-to- effective transition, not a particular implementation technology. 5. Terminology 5.1. Candidate Act A Candidate Act is a concrete operation that has been generated, selected, prepared, or requested but has not yet been permitted to acquire the external consequence represented by that operation. Examples include: HTTP method + URI + body RPC method + arguments payment destination + amount database operation + object network-control operation + parameters device command + target + state cloud operation + resource identifier Figure 9 A Candidate Act is not merely an abstract user intent. It represents the concrete operation proposed for effectuation. 5.2. Non-Effective State A Non-Effective State is a state in which a Candidate Act may be: * generated; * parsed; Das Expires 11 March 2027 [Page 12] Internet-Draft Attestation-Bound Execution Finality September 2026 * transformed; * queued; * simulated; * inspected; * hashed; * signed; or * validated, but cannot yet cause the protected external consequence. This property is central to execution finality. Validation that occurs after an irreversible external effect does not provide the same property. 5.3. Execution-Finality Validator An Execution-Finality Validator (EFV) is a logical component that evaluates a Candidate Act together with relevant validation inputs. Inputs can include: * Attestation Results; * workload identity; * calling identity; * target identity; * execution context; * authorization scope; * policy; * jurisdictional information; * resource state; * operation arguments; Das Expires 11 March 2027 [Page 13] Internet-Draft Attestation-Bound Execution Finality September 2026 * time; * nonce; * sequence state; * replay state; * risk state; and * application-specific conditions. An EFV may be implemented using a protected execution environment, trusted service, DPU, HSM, enclave, kernel component, gateway, or other enforcement-capable mechanism. 5.4. Protected Validation Evidence Protected Validation Evidence (PVE) is evidence produced after validation of a particular Candidate Act. PVE binds the authorization decision to the act or to a canonical representation of the act. PVE is not intended to be general bearer authority for unrelated operations. 5.5. Execution Handle An Execution Handle (EH) is an optional scoped authorization artifact derived from successful validation. An EH can authorize execution of the corresponding Candidate Act subject to constraints encoded directly or cryptographically referenced by the handle. An EH SHOULD be: * act-bound; * audience-bound where applicable; * short-lived; * replay-resistant; * non-transferable where feasible; and Das Expires 11 March 2027 [Page 14] Internet-Draft Attestation-Bound Execution Finality September 2026 * unusable for materially different operations. 5.6. Finality Sink A Finality Sink is the logical boundary at which a Candidate Act would first acquire the protected external effect. A Finality Sink verifies, reconstructs, or otherwise establishes the required validation state before permitting that transition. Examples include: * an API gateway; * database commit boundary; * storage controller; * cloud-control-plane endpoint; * payment execution service; * network egress gateway; * DPU; * SmartNIC; * hypervisor; * operating-system kernel; * service-mesh proxy; * industrial controller; * messaging service; or * receiving workload. A Finality Sink is a logical function. It need not be a separate physical device. 6. Architecture The basic architecture is: Das Expires 11 March 2027 [Page 15] Internet-Draft Attestation-Bound Execution Finality September 2026 +-----------------------+ | Workload / AI Agent | +-----------+-----------+ | | generates v +---------------+ | Candidate Act | +-------+-------+ | NON-EFFECTIVE | v +---------------------------------------+ | Execution-Finality Validator | | | | Inputs may include: | | | | - Attestation Result | | - workload identity | | - execution context | | - policy | | - Candidate Act parameters | | - target identity | | - freshness / nonce | | - authorization scope | +------------------+--------------------+ | validation success | v +----------------------+ | PVE / Execution | | Handle | +----------+-----------+ | v +---------------+ | Finality Sink | +-------+-------+ | EFFECTIVE | v +----------------+ | External Effect| +----------------+ Das Expires 11 March 2027 [Page 16] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 10 The principal security property is that the protected external effect is dependent upon successful finality verification. The invariant is that effectuation through a protected path depends on successful verification of authorization bound to the security- relevant content of the Candidate Act. Neither the request representation nor an Attestation Result functions as unrestricted authority for a materially different act. 7. Binding Attestation to a Candidate Act Attestation information can form part of the authorization context. Conceptually: Attestation Result + Workload Identity + Candidate Act + Policy / Context | v Execution-Finality Validation | v Act-Bound PVE / EH Figure 11 The binding can be constructed over a canonical representation: act_digest = HASH(canonical_candidate_act) Figure 12 Validation evidence can then conceptually bind: Das Expires 11 March 2027 [Page 17] Internet-Draft Attestation-Bound Execution Finality September 2026 validation_binding = { act_digest, workload_identity, attestation_reference, target, authorization_scope, issued_at, expires_at, nonce, policy_reference } Figure 13 This document does not mandate this encoding. The important property is that authorization of Candidate Act A cannot normally be reused to effect Candidate Act B where B differs in a security-relevant parameter. For example: authorized: transfer( destination = A, amount = 100 ) Figure 14 must not silently become authority for: transfer( destination = B, amount = 100000 ) Figure 15 because the workload identity and execution environment remain unchanged. 8. Why Attestation Alone Is Not the Binding Consider the following lifecycle: Das Expires 11 March 2027 [Page 18] Internet-Draft Attestation-Bound Execution Finality September 2026 T0 workload environment is attested T1 Relying Party accepts Attestation Result T2 workload processes external data T3 model generates Candidate Act A T4 external context changes T5 model generates Candidate Act B T6 operation reaches consequential system Figure 16 An Attestation Result can remain highly valuable throughout this lifecycle. However, the authorization question at T6 may depend on information not represented solely by the fact that the environment was successfully attested at T0. For example: * the exact operation; * destination; * amount; * requested resource; * caller; * current policy; * tenant; * target; * time; * current system state; or * authorization scope. Das Expires 11 March 2027 [Page 19] Internet-Draft Attestation-Bound Execution Finality September 2026 Execution-finality binding therefore allows attestation to remain an important trust input while independently binding authority to the concrete consequential operation. 9. Relationship to the RATS Architecture [RFC9334] defines a Relying Party as an entity that consumes Attestation Results and applies an appraisal policy for Attestation Results. The Relying Party may make application-specific decisions, including authorization decisions. This architecture is compatible with that model. An implementation can model the Execution-Finality Validator as, or as part of, a Relying Party. For example: Attester | | Evidence v Verifier | | Attestation Result v Execution-Finality Validator / Relying Party | | act-bound validation v Finality Sink Figure 17 The proposed extension is therefore not: RATS cannot authorize Figure 18 but: Das Expires 11 March 2027 [Page 20] Internet-Draft Attestation-Bound Execution Finality September 2026 RATS Attestation Result | v application-specific appraisal | + concrete Candidate Act | v act-bound finality authorization Figure 19 This allows existing RATS mechanisms to participate without making the Attestation Result itself a universal execution credential. 10. Composite CPU and Confidential-Accelerator Environments Modern confidential workloads can span multiple independently attestable components. For example: +------------------------------------------+ | Confidential VM | | | | CPU TEE | | | | | +------ Confidential GPU | | | | | +------ DPU / SmartNIC | | | +------------------------------------------+ Figure 20 Composite attestation can establish properties across those components. Execution finality addresses the later transition: Das Expires 11 March 2027 [Page 21] Internet-Draft Attestation-Bound Execution Finality September 2026 composite trusted environment | v compute | v Candidate Act | v act-specific validation | v Finality Sink | v external effect Figure 21 This permits a system to benefit from heterogeneous attestation while avoiding an assumption that all outputs subsequently emitted by that environment necessarily carry identical authority. 11. AI Accelerator Example An AI inference workload executes using an accelerator. The accelerator produces model output that an agent framework interprets as: tool = cloud.compute.delete_instance arguments = { instance: "production-47" } Figure 22 The output is first represented as: CandidateAct { action: "cloud.compute.delete_instance", resource: "production-47" } Figure 23 It remains non-effective. Das Expires 11 March 2027 [Page 22] Internet-Draft Attestation-Bound Execution Finality September 2026 The validator evaluates: workload identity + accelerator / platform Attestation Result + requested action + resource + tenant + policy + freshness Figure 24 If permitted, the validator produces validation evidence bound to: HASH( "cloud.compute.delete_instance" || "production-47" ) Figure 25 The cloud-control endpoint acts as the Finality Sink. Without acceptable evidence for that Candidate Act, the deletion is not performed. The accelerator remains responsible for computation. The Finality Sink remains responsible for consequence. 12. Hyperscale Deployment A hyperscale deployment can place the architecture across existing infrastructure. Example: Das Expires 11 March 2027 [Page 23] Internet-Draft Attestation-Bound Execution Finality September 2026 +-------------+ | AI workload | +------+------+ | v +-------------+ | GPU cluster | +------+------+ | | Candidate Act v +------------------+ | DPU / SmartNIC | | or local gateway | +--------+---------+ | | validated operation v +------------------+ | Data-center | | network fabric | +--------+---------+ | v +------------------+ | Service / API / | | storage endpoint | | Finality Sink | +--------+---------+ | v External Effect Figure 26 Other deployments may place validation at an API gateway: GPU workload | Candidate Act | network fabric | API gateway [EFV + Finality Sink] | backend Das Expires 11 March 2027 [Page 24] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 27 or at the destination: GPU workload | Candidate Act + PVE | network | destination service [Finality Sink] Figure 28 The architecture therefore does not require adding validation processing to each accelerator interconnect packet. 13. DPU and SmartNIC Deployment DPUs and SmartNICs provide a particularly useful implementation location where infrastructure operators wish to separate application computation from enforcement. Conceptually: Host CPU / GPU | Candidate Act | v +----------------------+ | DPU / SmartNIC | | | | finality verification| +----------+-----------+ | authorized | v network egress Figure 29 Such a design can provide a hardware-separated enforcement point without requiring modifications to the model or accelerator instruction stream. Das Expires 11 March 2027 [Page 25] Internet-Draft Attestation-Bound Execution Finality September 2026 However, this architecture does not require that a DPU or SmartNIC perform this function. 14. Network Fabric Considerations Execution finality is independent of network bandwidth and transport technology. A Candidate Act can traverse: * PCIe; * accelerator interconnects; * Ethernet; * InfiniBand; * optical networks; * service meshes; * QUIC; * HTTP; * RPC protocols; or * other transports. The fabric answers whether information can be moved. Execution finality answers whether the consequential operation represented by that information is permitted to acquire effect. Accordingly, the architecture does not require per-packet authorization of ordinary data-plane traffic. Validation can occur only at security-relevant consequence boundaries. 15. Relationship to Workload Identity Workload identity establishes who or what a workload represents. Execution finality addresses what a particular workload instance is permitted to cause through a particular Candidate Act. Das Expires 11 March 2027 [Page 26] Internet-Draft Attestation-Bound Execution Finality September 2026 The relationship can therefore be expressed as: Workload identity | +-------------------+ | v Candidate Act | v act authorization | v external effect Figure 30 A workload identity authenticates a workload principal; the authorization decision remains scoped to the requested operation and resource. Conversely, an execution-finality system benefits from strong workload identity because the authorization evidence can be bound to the workload that generated or requested the operation. The architecture can therefore consume workload identities and workload credentials defined by systems such as WIMSE [WIMSE]. 16. Separation of Identity, Trust, Authority, and Finality The architecture distinguishes four questions. These questions may be handled by one implementation component or several. They remain logically distinct. 16.1. Identity Who or what is this workload? Figure 31 16.2. Trust What properties can be established about the environment? Figure 32 Remote attestation primarily contributes here. Das Expires 11 March 2027 [Page 27] Internet-Draft Attestation-Bound Execution Finality September 2026 16.3. Authority Is this concrete operation permitted under the relevant identity, trust state, scope, policy, and context? Figure 33 16.4. Finality Has the required authorization been established at the boundary where the operation would acquire consequence? Figure 34 17. Candidate Act Canonicalization Where a cryptographic digest is used to bind authorization to a Candidate Act, security-relevant fields need a deterministic representation. For an HTTP operation this may include: method scheme authority target path selected headers body digest target identity Figure 35 For an RPC operation: service method canonical arguments target Figure 36 For an infrastructure operation: operation identifier resource identifier parameters tenant target environment Das Expires 11 March 2027 [Page 28] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 37 An implementation must ensure that semantically different acts cannot acquire the same authorization through ambiguous canonicalization. The exact canonicalization profile is protocol specific and is outside the scope of this document. 18. Freshness Validation evidence should be bounded in time or transaction context when stale authorization would create security risk. Possible mechanisms include: * expiry timestamps; * nonces; * challenge values; * sequence numbers; * monotonic counters; * transaction identifiers; or * freshness claims inherited from an underlying protocol. Long-lived execution evidence can undermine the act-specific property if it can be replayed outside its intended context. 19. Replay Resistance An attacker able to replay previously valid execution evidence may attempt to reproduce a consequential operation. A deployment can mitigate this by binding validation evidence to one or more of: Das Expires 11 March 2027 [Page 29] Internet-Draft Attestation-Bound Execution Finality September 2026 act digest transaction identifier nonce target audience execution epoch expiry sequence value single-use state Figure 38 A Finality Sink may maintain replay state where required. 20. Non-Bearer Properties A conventional bearer credential can confer authority primarily through possession. For high-consequence execution, a deployment may require stronger binding. An Execution Handle can therefore be bound to: * Candidate Act digest; * workload key; * workload identifier; * attested execution context; * target; * channel; * proof-of-possession key; * transaction identifier; or * combinations thereof. The goal is to prevent extraction of a valid authorization artifact from becoming general reusable authority. Das Expires 11 March 2027 [Page 30] Internet-Draft Attestation-Bound Execution Finality September 2026 21. Finality Sink Placement The Finality Sink should be located at a boundary where bypass would otherwise permit the protected external effect. Possible boundaries include: AI tool invocation gateway API ingress API egress database commit storage mutation cloud control plane DPU SmartNIC kernel hypervisor device controller payment processor receiving workload Figure 39 A system can contain multiple Finality Sinks for different consequence classes. For example: AI agent | Candidate Acts _________|_________ | | | v v v payment storage network sink sink sink Figure 40 22. Finality Sink Is Not Necessarily a New Appliance The term Finality Sink describes a logical enforcement boundary. Existing infrastructure can implement the function. Examples include: * an API gateway that verifies an act-bound proof; Das Expires 11 March 2027 [Page 31] Internet-Draft Attestation-Bound Execution Finality September 2026 * a database server that refuses mutation without corresponding authorization evidence; * a DPU that prevents unauthorized control traffic from leaving a host; * a hypervisor that mediates device operations; * an operating-system service that validates privileged actions; * a receiving workload that verifies proof before acting. A deployment therefore does not necessarily introduce an additional network hop. 23. Hot-Path and Cold-Path Processing A practical deployment should avoid placing expensive operations on every consequential hot path. The architecture permits separation between: Cold-path operations * attestation verification; * endorsement retrieval; * certificate-chain processing; * policy distribution; * reference-value processing; and * long-lived trust-context establishment. and: Hot-path operations * Candidate Act digest computation; * freshness verification; * context lookup; * policy decision; Das Expires 11 March 2027 [Page 32] Internet-Draft Attestation-Bound Execution Finality September 2026 * proof verification; and * finality enforcement. For example: COLD PATH GPU / CVM attestation | v Verifier | Attestation Result | cached trust context | +--------------------+ | v HOT PATH AI output -> Candidate Act | v lookup trust context | act-specific validation | v Finality Sink Figure 41 This allows expensive attestation operations to remain outside the per-act path where policy permits. 24. Legacy Deployment Execution-finality enforcement does not require immediate modification of all applications. A sidecar, gateway, DPU, service-mesh proxy, reverse proxy, API- management layer, or workload wrapper can mediate protected operations. Example: Das Expires 11 March 2027 [Page 33] Internet-Draft Attestation-Bound Execution Finality September 2026 Legacy AI application | | ordinary API request v +-----------------------+ | Finality sidecar | | | | creates Candidate Act | | validates / obtains | | PVE | +-----------+-----------+ | v external API Figure 42 This permits incremental deployment. 25. Failure Modes 25.1. Validation Failure If required validation fails, the Candidate Act remains non- effective. 25.2. Missing Attestation Context Where policy requires an acceptable Attestation Result and no acceptable result exists, validation fails. 25.3. Expired Validation Evidence Expired evidence is rejected where freshness is required. 25.4. Parameter Mutation If security-relevant Candidate Act parameters change after validation, the original validation binding no longer authorizes the modified act. 25.5. Finality Sink Unavailable A system should fail according to the consequence class. High-consequence systems will commonly fail closed. Other systems may define application-specific behavior. Das Expires 11 March 2027 [Page 34] Internet-Draft Attestation-Bound Execution Finality September 2026 26. Threat Model The architecture is intended to address threats including: * an AI workload generating an operation outside intended authority; * manipulation of Candidate Act parameters after validation; * replay of prior authorization evidence; * use of trusted-workload credentials for unauthorized operations; * propagation of general bearer authority through multiple workloads; * compromise of an application component outside a protected validation boundary; * confusion between attested execution and act authorization; and * bypass of the intended consequence-enforcement boundary. The architecture does not guarantee correctness of the underlying policy. It also does not prevent compromise of every component if the Finality Sink itself is fully compromised. 27. Security Considerations Execution-finality systems create a security dependency on correct identification of the consequence boundary. If an attacker can bypass the Finality Sink and reach another path capable of producing the same external effect, technical non- effectiveness is not established. Implementations therefore need to identify all relevant effectuation paths. Validation evidence should bind all security-relevant fields of a Candidate Act. Failure to bind a relevant argument can permit substitution attacks. For example, binding: operation = "transfer" Das Expires 11 March 2027 [Page 35] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 43 without binding: destination amount currency Figure 44 would normally provide inadequate protection for a payment operation. Attestation Results should not be interpreted beyond their defined semantics. A successful Attestation Result does not establish properties that were not measured, claimed, or appraised. Likewise, execution-finality validation does not establish that an AI model's reasoning is correct. It establishes only that the defined conditions for permitting a particular act were satisfied. Implementations should protect validator signing keys and other execution-authority material. Where possible, execution evidence should use proof-of-possession, audience restriction, act binding, freshness, or equivalent mechanisms instead of unrestricted bearer semantics. 28. Privacy Considerations Candidate Acts can contain sensitive information. Validation systems should avoid exposing unnecessary operation parameters. Where practical, deployments can validate cryptographic commitments or digests instead of transmitting full Candidate Act contents to unrelated components. Attestation information can also reveal platform characteristics. Existing RATS privacy guidance remains applicable. Implementations should minimize correlation identifiers and avoid creating unnecessarily persistent identifiers for AI workloads or users. Das Expires 11 March 2027 [Page 36] Internet-Draft Attestation-Bound Execution Finality September 2026 29. Example: Confidential AI Inference in a Hyperscaler Consider a tenant running an AI agent inside a confidential VM with confidential accelerators. The environment is remotely attested. CPU/CVM Evidence + GPU Evidence | v Composite Attestation | v Attestation Result Figure 45 The AI workload subsequently generates: Candidate Act: POST /v1/infrastructure/deploy tenant = T1 image = model-service-v4 environment = production region = R1 Figure 46 The operation remains non-effective. The validator evaluates: Candidate Act + Attestation Result + workload identity + tenant authorization + deployment policy + freshness Das Expires 11 March 2027 [Page 37] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 47 Successful validation produces evidence bound to the exact deployment request. The cloud control-plane API acts as the Finality Sink. Only after verification does: Candidate Act Figure 48 become: Effective Deployment Figure 49 The confidential-computing environment establishes trust in computation. Execution finality establishes the controlled transition from computation to consequence. 30. Example: DPU-Mediated AI Egress A GPU-hosted autonomous workload generates requests that leave a server. The host architecture provides a DPU-controlled network path. Das Expires 11 March 2027 [Page 38] Internet-Draft Attestation-Bound Execution Finality September 2026 +-----------------------+ | CPU + GPU | | | | AI workload | +-----------+-----------+ | Candidate Act | v +-----------------------+ | DPU | | | | finality verification | +-----------+-----------+ | authorized | v data-center fabric Figure 50 For protected operation classes, the DPU can require acceptable execution evidence before permitting the operation to reach its external destination. Normal network traffic does not need to be subjected to this mechanism unless policy classifies it as consequential. 31. Example: Multi-Workload Agent Chain An AI task can cross multiple workloads: User | v Agent A | v Planner B | v Tool Broker C | v Service D Figure 51 Das Expires 11 March 2027 [Page 39] Internet-Draft Attestation-Bound Execution Finality September 2026 Identity and trust can be propagated through the chain. However, the final consequential operation may depend on arguments generated only near the end of the workflow. Execution finality permits the final concrete operation to be validated independently of the fact that earlier workloads were authenticated or attested. authenticated chain | v concrete Candidate Act | v final act-specific validation | v external consequence Figure 52 32. Interoperability Requirements Future protocol work based on this architecture should support interoperability between: * Attestation Result producers; * workload-identity systems; * execution-finality validators; * AI runtimes; * gateways; * DPUs; * SmartNICs; * confidential-computing platforms; and * Finality Sinks. A protocol profile would need to define at least: 1. Candidate Act identification; Das Expires 11 March 2027 [Page 40] Internet-Draft Attestation-Bound Execution Finality September 2026 2. canonicalization; 3. act digest representation; 4. validation-evidence format; 5. workload binding; 6. attestation binding; 7. audience or target binding; 8. freshness; 9. replay protection; 10. error handling; and 11. cryptographic algorithm negotiation. These details are intentionally left for subsequent protocol documents. 33. Potential Protocol Flow A future protocol could use a flow similar to: Workload EFV Finality Sink | | | | Candidate Act | | |------------------>| | | | | | validation context / attestation | | | | | | | |<------------------| | | PVE / EH | | | | | Candidate Act + PVE/EH | |------------------------------------------>| | | | verify act | | binding | | | | effectuate | | | Figure 53 Das Expires 11 March 2027 [Page 41] Internet-Draft Attestation-Bound Execution Finality September 2026 Another deployment may have the Finality Sink request validation directly: Workload Finality Sink EFV | | | | Candidate Act | | |------------------>| | | | validation request | | |-------------------->| | | | | | validation result | | |<--------------------| | | | | | effectuate | Figure 54 The architecture permits both models. 34. Minimal Vendor-Neutral Proof-of-Concept Profile This section defines one deliberately narrow profile that can be implemented to test the architectural invariant. It is not a general Candidate Act format and does not register a new token type. Its purpose is to make the proposal falsifiable, permit independent implementations to exercise the same processing steps, and identify which parts require subsequent standardization. 34.1. Protected Operation The proof of concept protects one HTTP operation: POST https://payments.example/transfer Content-Type: application/json {"destination":"account-B","amount":100,"currency":"USD"} Figure 55 The API gateway is the Finality Sink. The downstream payment test service is reachable only through that gateway. The service performs no real financial transfer; it records an accepted test operation. 34.2. Canonical CandidateAct The proof of concept represents the security-relevant operation as the following CBOR map. Integer labels are used only for this experimental profile: Das Expires 11 March 2027 [Page 42] Internet-Draft Attestation-Bound Execution Finality September 2026 candidate-act = { 1: 1, ; profile version 2: "POST", ; uppercase HTTP method 3: tstr, ; lowercase authority 4: tstr, ; normalized absolute path 5: bstr .size 32, ; SHA-256 of request body bytes 6: tstr, ; intended Finality Sink identifier 7: tstr ; transaction identifier } Figure 56 The body is serialized as UTF-8 JSON using the fixed member order and no insignificant whitespace shown in the test vector. This restriction is suitable only for the proof of concept; a reusable HTTP profile would need a complete content canonicalization rule. The Candidate Act is encoded using the deterministic-encoding requirements of [RFC8949]. The act digest is: act_digest = SHA-256(deterministic-CBOR(candidate-act)) Figure 57 The gateway reconstructs the Candidate Act from the received request rather than trusting a digest supplied by the workload. Any change to the method, authority, path, body bytes, audience, or transaction identifier therefore changes the reconstructed act or its digest. 34.3. EAT and Attestation-Result Input The EFV consumes one valid EAT conforming to [RFC9711] or an Attestation Result produced by a configured Verifier from that EAT. The proof-of-concept configuration identifies the accepted EAT profile, trust anchor, required claims, freshness rule, and appraisal policy. Accepting a syntactically valid token without applying that profile and policy is an error. After successful appraisal, the EFV derives: attestation_context_id = SHA-256(verifier_identifier || appraisal_result_bytes) Figure 58 Das Expires 11 March 2027 [Page 43] Internet-Draft Attestation-Bound Execution Finality September 2026 The byte encoding and semantics of appraisal_result_bytes are fixed by the proof-of-concept configuration. The Execution Handle carries this derived identifier, not the original Evidence, so that the gateway need not repeat full Evidence appraisal on the per-operation path. 34.4. Signed Execution Handle Following successful appraisal and operation-specific policy evaluation, the EFV issues a COSE_Sign1 object as specified by [RFC9052]. Its payload is the deterministic CBOR encoding of: execution-handle = { 1: 1, ; profile version 2: bstr .size 32, ; act_digest 3: tstr, ; workload identity 4: bstr .size 32, ; attestation_context_id 5: tstr, ; Finality Sink audience 6: uint, ; issued-at, epoch seconds 7: uint, ; expiry, epoch seconds 8: bstr, ; unpredictable nonce 9: tstr ; transaction identifier } Figure 59 The protected COSE header contains the algorithm identifier and a key identifier. The initial proof of concept uses one mandatory signing algorithm selected in its published implementation manifest. Algorithm agility and negotiation are outside this experimental profile. The EFV signing key is distinct from an Attester key, and possession of an EAT does not permit issuance of an Execution Handle. 34.5. Finality-Sink Processing For the protected endpoint, the gateway MUST reject the request unless all of the following checks succeed: 1. An Execution Handle is present in the configured request field. 2. The COSE_Sign1 structure and EFV signature are valid under a configured key. 3. The profile version and signing algorithm are accepted. 4. The audience equals the gateway's configured Finality Sink identifier. Das Expires 11 March 2027 [Page 44] Internet-Draft Attestation-Bound Execution Finality September 2026 5. The current time is within the issued-at and expiry interval. 6. The transaction identifier in the handle equals the transaction identifier used to reconstruct the request. 7. The gateway reconstructs and deterministically encodes the Candidate Act, and its SHA-256 digest equals act_digest in the handle. 8. The nonce has not previously been consumed for that EFV and audience. The gateway MUST record the nonce as consumed atomically with release of the request to the test service. A failed check produces no downstream request. The proof of concept distinguishes malformed credentials, invalid authorization, expired authorization, act mismatch, and replay in internal logs; an external deployment may intentionally return less specific errors. 34.6. Required Test Vectors A published implementation of this profile includes reproducible input bytes, deterministic Candidate Act bytes, act digests, COSE_Sign1 bytes, public verification keys, and expected results for at least the following cases: Das Expires 11 March 2027 [Page 45] Internet-Draft Attestation-Bound Execution Finality September 2026 +======+=======================================+==================+ | Case | Variation | Expected result | +======+=======================================+==================+ | V1 | Exact request and unused valid handle | Accepted once | +------+---------------------------------------+------------------+ | V2 | Missing handle | Rejected | +------+---------------------------------------+------------------+ | V3 | Amount changed from 100 to 100000 | Act mismatch | +------+---------------------------------------+------------------+ | V4 | Destination changed | Act mismatch | +------+---------------------------------------+------------------+ | V5 | Method or path changed | Act mismatch | +------+---------------------------------------+------------------+ | V6 | Expired handle | Rejected | +------+---------------------------------------+------------------+ | V7 | Second use of the V1 handle | Replay rejected | +------+---------------------------------------+------------------+ | V8 | Different Finality Sink audience | Rejected | +------+---------------------------------------+------------------+ | V9 | Modified COSE payload or signature | Rejected | +------+---------------------------------------+------------------+ | V10 | Unacceptable or stale EAT at issuance | No handle issued | +------+---------------------------------------+------------------+ Table 1 34.7. Latency Measurement and Publication Performance claims require measured results. A proof-of-concept report therefore records software version, hardware, operating system, cryptographic algorithm, key type, gateway topology, replay- store implementation, concurrency, request-body size, sample count, and warm-up procedure. The report separately measures: * cold-path EAT verification and appraisal; * Candidate Act construction and digest computation; * Execution Handle issuance; * gateway signature, binding, freshness, and replay verification; * end-to-end protected-request latency; and * the same request through the gateway without finality processing as the baseline. Das Expires 11 March 2027 [Page 46] Internet-Draft Attestation-Bound Execution Finality September 2026 Results are reported as throughput and latency distributions including median, 95th percentile, and 99th percentile, rather than as an unsupported single latency value. 34.8. Implementation Status A runnable, vendor-neutral reference implementation of the minimal experimental profile defined in this document is now available as an accompanying archive, execution-finality-reference-v0.1.0.tar.gz, containing the complete runnable source code, implementation documentation, security guidance, deterministic cryptographic test vectors, automated tests, benchmark scripts, measured benchmark output, deployment files and the corresponding Internet-Draft. The source repository is published at [EF-GPU-GITHUB], and an archived, citable snapshot with a persistent identifier is published at [EF-GPU-ZENODO]. This section describes what the accompanying software demonstrates, how it is structured, and its production-integration boundaries. The software is real, executable reference code rather than pseudocode, and is appropriately described as a working, production-oriented reference implementation and interoperability demonstrator. It is not production-certified software and has not been represented as an implementation integrated into any commercial GPU, DPU, SmartNIC or cloud platform. The protected effect in the reference implementation is an atomic commit to a local SQLite effects table; no real funds move, and the software is not a certified payment product. Implemented Components The reference implementation includes: * deterministic CBOR encoding conforming to the relevant [RFC8949] requirements, using a strict-decoding subset; * COSE_Sign1 signing and verification ([RFC9052]) using Ed25519 (COSE alg=-8); * signed Entity Attestation Token issuance, verification and appraisal, using EAT/CWT claims plus private experimental claims for workload and measurement identity; * canonical Candidate Act construction, including a fixed canonical JSON body for a deliberately narrow /transfer operation used as the demonstrator act; * SHA-256 act-specific cryptographic binding; Das Expires 11 March 2027 [Page 47] Internet-Draft Attestation-Bound Execution Finality September 2026 * signed, audience-bound and transaction-bound Execution Handles, issued from a signing key distinct from the Attester key so that an EAT cannot itself be presented to the gateway as execution authority; * an Execution-Finality Validator (EFV) service; * an enforcing HTTP API gateway operating as the Finality Sink; * atomic nonce consumption and replay protection using SQLite in WAL mode with synchronous=FULL; * bounded request and token sizes, short-lived handles, and clock- skew checking; * non-diagnostic external denial responses paired with internal structured denial reasons; * deterministic test-vector generation; and * reproducible latency microbenchmarks. Reference Security Flow The two reference services interact as follows: 1. an Attester issues a COSE_Sign1 EAT for an identified workload; 2. the EFV verifies and appraises that EAT; 3. the EFV evaluates the exact canonical Candidate Act, here a canonical payment request; 4. the EFV signs an act-bound COSE_Sign1 Execution Handle; 5. the gateway, acting as Finality Sink, reconstructs the Candidate Act from the received request; 6. the gateway verifies the handle's signature, audience, transaction identity, validity interval, act digest, and nonce; and 7. the gateway atomically consumes the nonce and records the protected effect. Das Expires 11 March 2027 [Page 48] Internet-Draft Attestation-Bound Execution Finality September 2026 Test Results Eleven automated tests pass against the reference implementation, consistent with the required cases in Section 34.6, including an end- to-end HTTP test that starts the EFV and Finality Sink, obtains an act-bound handle, permits the exact authorized request once, and confirms that replay cannot create a second committed effect. Measured Benchmarks Local microbenchmarks measured approximately 140 microseconds median for EAT appraisal, 1.5 microseconds for Candidate Act construction, 50 microseconds for Execution Handle issuance, and approximately 140 microseconds for Execution Handle verification. These measurements characterize only the supplied portable implementation and its execution environment; they are not claims about GPU, DPU, SmartNIC, confidential-accelerator or hyperscale production performance. Production Integration Boundaries The core verifier is designed for embedding, but production deployment would additionally require, at minimum: * terminating TLS at a hardened ingress, or adding TLS to the service process; * placing the downstream effect behind the Finality Sink with no bypass route; * protected or hardware-backed key management, such as an HSM- or KMS-backed EFV signing key, rather than a filesystem private key; * platform-specific trust anchors and replacement of the experimental EAT claim profile with the deployment's registered EAT profile; * distributed and rollback-resistant replay state, such as a replicated transactional store, where more than one gateway instance can commit the same consequence; * non-bypassable effectuation paths and integration with the relevant accelerator, workload or cloud-control infrastructure; * operational monitoring, including logs, metrics, rate limiting, authorization policy, key rotation, backup and incident response; and Das Expires 11 March 2027 [Page 49] Internet-Draft Attestation-Bound Execution Finality September 2026 * independent security review, including threat modeling, dependency review, fuzzing and penetration testing. The reference implementation proves executable feasibility for the narrow profile above and supplies reproducible negative tests and byte-level vectors. It does not prove patent novelty, IETF adoption, universal applicability, hyperscale performance, or suitability for real financial processing. 35. Why This Matters for AI Infrastructure AI runtimes increasingly translate generated output into API, control-plane, and storage operations. Infrastructure may already provide several sources of identity and appraisal information: CPU attestation GPU attestation confidential VMs accelerator isolation DPU isolation workload identity service identity Figure 60 The proposal defines how those inputs can participate in an operation-specific authorization decision whose verification is enforced at the relevant effectuation boundary: a consequential output remains non-effective until the authorization required for that exact operation is established at its consequence boundary. Figure 61 This is an application of attestation and workload identity to consequence-bearing operations; it is not a claim that the underlying attestation mechanisms are deficient. 36. Operational Considerations Deployments should classify operations according to consequence. It is neither necessary nor desirable to apply expensive finality processing to every tensor operation, memory transaction, or network packet. Das Expires 11 March 2027 [Page 50] Internet-Draft Attestation-Bound Execution Finality September 2026 Instead, enforcement can occur at semantically meaningful boundaries such as: create delete transfer deploy publish send commit open release modify authorize Figure 62 This permits high-throughput accelerator and network fabrics to operate normally while protected consequences receive stronger authorization semantics. 37. Discussion of Latency A common concern with additional authorization boundaries is latency. This architecture permits several optimizations. First, full attestation verification can occur on the cold path. Second, Attestation Results or derived trust context can be cached according to their security properties. Third, Candidate Act validation can use compact digests instead of transmitting large model outputs. Fourth, validation can be colocated with a DPU, gateway, service mesh, kernel component, API endpoint, or target workload. Fifth, a Finality Sink can perform local cryptographic verification without a new network round trip where appropriate. Accordingly, the architecture does not require remote attestation to be repeated for every model output. 38. Open Questions The following questions are intentionally left open for IETF discussion: Das Expires 11 March 2027 [Page 51] Internet-Draft Attestation-Bound Execution Finality September 2026 1. Should an act-bound execution authorization be represented as a profile of an existing token format or as a new artifact? 2. Which Candidate Act canonicalizations are sufficiently generic for reuse? 3. Should the Attestation Result be carried directly, referenced by digest, or represented through derived trust context? 4. How should workload identity and proof-of-possession credentials be bound to execution-finality evidence? 5. Which components naturally perform the Finality Sink role in cloud and accelerator environments? 6. Can existing RATS conceptual messages be profiled for this use case without creating a new protocol? 7. Which parts belong in RATS and which are better handled by WIMSE or application-specific authorization protocols? 8. How should multi-verifier and composite-attestation results be represented in act-specific validation? 9. How should the architecture handle long-running agentic workflows in which authorization context changes between planning and execution? 10. Which mechanisms provide the lowest-latency implementation in GPU, DPU, SmartNIC, service-mesh, and hyperscaler environments? 39. Related Work by the Same Author This document applies the underlying execution-finality architecture to GPU, AI accelerator, DPU, SmartNIC, and confidential-computing infrastructure specifically. The same underlying architecture is applied to other domains in a set of companion Internet-Drafts, referenced here for readers who want the broader picture; none of them is a prerequisite for reading this document. Full URLs are given directly, in addition to the formal citations in Section 42, for ease of reference. * [DAS-EF-PROTOCOL-LAYER], "The Missing Execution-Finality Protocol Layer of the Internet" (draft-das-execution-finality-protocol- layer) — an umbrella synthesis draft that formalizes the shared vocabulary (Candidate Act, Non-Effective State, Protected Enforcement Domain, Execution Handle, Finality Sink) used across this document and the drafts below, and surveys its application Das Expires 11 March 2027 [Page 52] Internet-Draft Attestation-Bound Execution Finality September 2026 across a wider range of industry domains: https://datatracker.ietf.org/doc/draft-das-execution-finality- protocol-layer/ (https://datatracker.ietf.org/doc/draft-das- execution-finality-protocol-layer/) * [DAS-AGENTIC-TOOL-BINDING], "tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP" (draft-das-agentic-tool-binding) — binds the same Candidate Act model onto agentic tool-call interfaces, including tool_use/ computer_use, function calling, and MCP tools/call: https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/ (https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/) * [DAS-EF-AI-INTEROP], "Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture" (draft-das- execution-finality-ai-interoperability) — applies the architecture to third-party AI interoperability obligations under the EU Digital Markets Act: https://datatracker.ietf.org/doc/draft-das- execution-finality-ai-interoperability/ (https://datatracker.ietf.org/doc/draft-das-execution-finality-ai- interoperability/) * [DAS-FRONTIER-MODEL-EXTRACTION], "Beyond Attestation: An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive Frontier AI Model Information" (draft-das-rats-frontier-model- extraction) — applies the architecture to controlling release of sensitive frontier-model inference information such as logits, embeddings, and hidden states: https://datatracker.ietf.org/doc/ draft-das-rats-frontier-model-extraction/ (https://datatracker.ietf.org/doc/draft-das-rats-frontier-model- extraction/) * [DAS-ENTERPRISE-AI-OUTPUT-FINALITY], "A Compromised AI Server Must Not Become a Map of the Enterprise: Non-Joinable Vaults and Output-Release Finality" (draft-das-enterprise-ai-output-finality) — applies a related non-joinability and output-release-finality architecture to enterprise AI deployments handling sensitive internal data: https://datatracker.ietf.org/doc/draft-das- enterprise-ai-output-finality/ (https://datatracker.ietf.org/doc/ draft-das-enterprise-ai-output-finality/) * [DAS-PROTOCOLS-ENTERPRISE-AI], "Architecting Resilience for Enterprise AI: Preventing Data Reconstruction, Exfiltration, and Unauthorized Consequence in Compromised AI Environments (DAS Protocols)" (draft-das-protocols-enterprise-ai) — a fuller technical elaboration of the same enterprise-AI non-joinability Das Expires 11 March 2027 [Page 53] Internet-Draft Attestation-Bound Execution Finality September 2026 and output-finality architecture: https://datatracker.ietf.org/doc/draft-das-protocols-enterprise- ai/ (https://datatracker.ietf.org/doc/draft-das-protocols- enterprise-ai/) The reference implementation accompanying this document (Section 34.8) is published at [EF-GPU-GITHUB]: https://github.com/sangmdas/Execution-Finality-for-GPU-AI- Accelerators-and-Confidential-Workloads/ (https://github.com/sangmdas/Execution-Finality-for-GPU-AI- Accelerators-and-Confidential-Workloads/), with an archived, citable snapshot at [EF-GPU-ZENODO]: https://zenodo.org/records/22308384 (https://zenodo.org/records/22308384). *IPR disclosure, for transparency:* the broader execution-finality architecture underlying this document and the companion drafts above is the subject of pending patent applications by the author, including published international application [WIPO-WO2026150382], WIPO Publication No. WO 2026/150382, available at: https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2026150382 (https://patentscope.wipo.int/search/en/ detail.jsf?docId=WO2026150382). This identification is provided for transparency and does not itself determine the scope, validity, or applicability of any claim to this document's contents; a separate IPR disclosure is filed with the IETF Secretariat as applicable under BCP 79. 40. IANA Considerations This document has no IANA actions. Future protocol specifications based on this architecture may require registration of media types, token claims, CBOR labels, HTTP fields, or other protocol identifiers. 41. Normative References [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, December 2020, . Das Expires 11 March 2027 [Page 54] Internet-Draft Attestation-Bound Execution Finality September 2026 [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", RFC 9052, August 2022, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "Entity Attestation Token (EAT)", RFC 9711, April 2025, . 42. Informative References [WIMSE] IETF WIMSE Working Group, "Workload Identity in Multi System Environments (WIMSE)". IETF Workload Identity in Multi System Environments work. [TDX-CGPU-EAR] Kostal, G., Yeluri, R., and D. Kumar, "EAT Attestation Result (EAR) profile for Intel Trust Domain Extensions (TDX) + Confidential GPU (C-GPU) composite attestation". Work in progress. [NVIDIA-ATTESTATION] NVIDIA Corporation, "NVIDIA Attestation Suite: NVIDIA Remote Attestation Service (NRAS), Reference Integrity Manifest (RIM) Service, and OCSP Service", . Vendor documentation, cited informatively in Appendix "FAQ 26. What would be required for a genuine NVIDIA or accelerator integration?" as one example of a publicly documented accelerator attestation stack. Cited for illustrative and explanatory purposes only; this document is vendor- neutral, does not depend on NVIDIA hardware or software, and neither describes nor claims any integration with, review by, or endorsement from NVIDIA Corporation. [EF-GPU-GITHUB] Das, S., "Execution-Finality-for-GPU-AI-Accelerators-and- Confidential-Workloads (source repository)", . Source repository for the reference implementation described in Section 34.8. Das Expires 11 March 2027 [Page 55] Internet-Draft Attestation-Bound Execution Finality September 2026 [EF-GPU-ZENODO] Das, S., "From Attested GPU Computation to Authorized Action: Execution Finality for AI Accelerators and Confidential Workloads", 2026, . Archived, citable snapshot of the reference implementation and accompanying material described in Section 34.8. [DAS-PROTOCOLS-ENTERPRISE-AI] Das, S., "Architecting Resilience for Enterprise AI: Preventing Data Reconstruction, Exfiltration, and Unauthorized Consequence in Compromised AI Environments (DAS Protocols)", Work in Progress, Internet-Draft, draft- das-protocols-enterprise-ai, August 2026, . Work in progress. Applies the broader execution-finality/DAS Protocols architecture to enterprise-data reconstruction and output release. [DAS-FRONTIER-MODEL-EXTRACTION] Das, S., "Beyond Attestation: An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive Frontier AI Model Information", Work in Progress, Internet-Draft, draft-das-rats-frontier-model-extraction, August 2026, . Work in progress. Companion RATS-area application of execution finality to release of sensitive frontier-model inference information. [DAS-ENTERPRISE-AI-OUTPUT-FINALITY] Das, S., "A Compromised AI Server Must Not Become a Map of the Enterprise: Non-Joinable Vaults and Output-Release Finality", Work in Progress, Internet-Draft, draft-das- enterprise-ai-output-finality, 2026, . Work in progress. Das Expires 11 March 2027 [Page 56] Internet-Draft Attestation-Bound Execution Finality September 2026 [DAS-EF-AI-INTEROP] Das, S., "Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture", Work in Progress, Internet-Draft, draft-das-execution- finality-ai-interoperability, 2026, . Work in progress. Applies execution finality to third-party AI interoperability obligations under the EU Digital Markets Act. [DAS-AGENTIC-TOOL-BINDING] Das, S., "tool_use Is Not invoke(): Binding Execution- Finality to Agentic Tool-Call Interfaces and MCP", Work in Progress, Internet-Draft, draft-das-agentic-tool-binding, August 2026, . Work in progress. Binds the Candidate Act model onto tool_use/ computer_use, function- calling, and MCP tools/call interfaces. [DAS-EF-PROTOCOL-LAYER] Das, S., "The Missing Execution-Finality Protocol Layer of the Internet", Work in Progress, Internet-Draft, draft- das-execution-finality-protocol-layer, 2026, . Work in progress. Umbrella/ synthesis draft formalizing the shared execution-finality vocabulary (Candidate Act, Non-Effective State, Protected Enforcement Domain, Execution Handle, Finality Sink) applied across this document and the other companion drafts listed above. [WIPO-WO2026150382] Das, S., "International Patent Publication WO 2026/150382", 2026, . Published international patent application by the author, disclosed here for transparency in relation to the execution-finality architecture described in this document and the companion drafts in Section 39. Identification of this publication is informational only and does not itself determine the scope, validity, or applicability of any claim to this document's contents. Das Expires 11 March 2027 [Page 57] Internet-Draft Attestation-Bound Execution Finality September 2026 Appendix A. Architectural Summary The complete transition can be summarized as: TRUST PLANE Evidence / Attestation | v Verifier | v Attestation Result | | v COMPUTE PLANE CPU / GPU / NPU / accelerator / AI | v computation | v Candidate Act | NON-EFFECTIVE | v AUTHORITY PLANE workload identity + attestation context + Candidate Act + policy | v Execution-Finality Validator | v act-bound PVE / EH Das Expires 11 March 2027 [Page 58] Internet-Draft Attestation-Bound Execution Finality September 2026 | v FINALITY PLANE Finality Sink | v EXTERNAL EFFECT Figure 63 The principal distinction is: ENVIRONMENT APPRAISAL + WORKLOAD AUTHENTICATION + OPERATION-SPECIFIC POLICY | v ACT-BOUND AUTHORIZATION | v VERIFICATION AT EFFECTUATION BOUNDARY Figure 64 Appendix B. Concise Statement for Discussion This document explores a narrow interoperability question: How can a Relying Party's appraisal input and an authenticated workload identity be incorporated into authorization evidence for one canonically represented operation, with verification enforced before the protected effect is committed? The mechanism is intended to reuse existing attestation and identity infrastructure rather than replace it. Appendix C. Technical FAQ and Anticipated Engineering Questions This appendix addresses technical questions likely to arise when considering attestation-bound execution finality in relation to RATS, WIMSE, confidential computing, AI accelerators, DPUs, SmartNICs, and hyperscale infrastructure. Das Expires 11 March 2027 [Page 59] Internet-Draft Attestation-Bound Execution Finality September 2026 FAQ 1. Isn't this already what a RATS Relying Party does? *Question* RFC 9334 already states that a Relying Party can consume an Attestation Result and use its own appraisal policy to make an application-specific authorization decision. Why is another execution-finality architecture necessary? *Answer* The proposed architecture does not change that RATS property. A RATS Relying Party can absolutely decide whether an Attester should be allowed to perform an operation. The narrower problem addressed here is whether the result of that decision is cryptographically and operationally bound to the exact consequential operation that eventually reaches the effectuation boundary. The distinction is: RATS: Evidence | Verifier | Attestation Result | Relying Party | application-specific decision Figure 65 The proposed execution-finality composition adds: Das Expires 11 March 2027 [Page 60] Internet-Draft Attestation-Bound Execution Finality September 2026 Attestation Result + Candidate Act + workload identity + policy/context | v act-specific authorization | v protected act binding | v Finality Sink | v External Effect Figure 66 The additional property is end-to-end correspondence: the operation evaluated by the authorization function is the operation accepted at the protected effectuation boundary, including its security-relevant arguments. A RATS Relying Party can be the Execution-Finality Validator, the Finality Sink, or both. The terminology is therefore intended to specialize an application of RATS rather than introduce an alternative attestation architecture. *RATS relevance:* direct. RFC 9334 already provides the Attester, Verifier, Attestation Result, Relying Party, Evidence, and appraisal concepts needed as inputs. *WIMSE relevance:* workload identity can provide the authenticated workload identity used in the Relying Party's act-specific decision. FAQ 2. Is this simply AR4SI applied to individual requests? *Question* RATS already has Attestation Results for Secure Interactions. Why is an additional mechanism necessary? *Answer* Das Expires 11 March 2027 [Page 61] Internet-Draft Attestation-Bound Execution Finality September 2026 AR4SI is highly complementary. AR4SI describes reusable information that allows a Relying Party to evaluate properties such as identity, trustworthiness, and freshness and then determine whether secure interaction should be allowed. Execution finality applies a distinct authorization decision to operations within an accepted secure interaction when their consequence, target, or arguments require different policy treatment. For example, an attested AI workload might be permitted to communicate with a cloud-control service. During the same authenticated interaction it could generate: GET /instances Figure 67 followed later by: DELETE /instances/production-47 Figure 68 The secure-interaction trust state can remain valid for both messages while the authorization requirements differ substantially. Execution finality therefore permits: AR4SI trust information | v persistent/cached trust context | +------------------+ | Candidate Act A | authorization | Finality Figure 69 and independently: Das Expires 11 March 2027 [Page 62] Internet-Draft Attestation-Bound Execution Finality September 2026 same trust context | +------------------+ | Candidate Act B | different decision Figure 70 There is no requirement to repeat hardware attestation for every operation. *RATS relevance:* AR4SI can provide reusable trustworthiness inputs to the execution-finality validator. Current AR4SI work explicitly focuses on information provided to Relying Parties for decisions about secure interaction. *WIMSE relevance:* the authenticated workload associated with the secure interaction can be identified using WIMSE credentials while individual operations receive independent authorization. FAQ 3. How does this interact with composite CPU, CVM, GPU, and accelerator attestation? *Question* A confidential workload may already produce composite attestation covering a CPU TEE, confidential VM, and confidential GPU. Why is Candidate Act validation separate? *Answer* Composite attestation and Candidate Act validation operate at different semantic layers. For example: Intel TDX Evidence + Confidential GPU Evidence | v Composite appraisal | v Attestation Result Das Expires 11 March 2027 [Page 63] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 71 can establish properties of the combined confidential-computing environment. That result becomes an input to: Attestation Result + Candidate Act + workload identity + authorization context | v Execution-Finality Decision Figure 72 A stable composite appraisal can be reused while individual operations receive different authorization outcomes. For example: Act 1 = read object X Act 2 = modify object X Act 3 = delete object X Act 4 = transmit object X to workload Y Figure 73 The attested environment can remain identical. The authorization decision need not. The referenced TDX+C-GPU Attestation Result profile [TDX-CGPU-EAR] illustrates a composite appraisal input that could be consumed by the proposed authorization flow. The architecture also accommodates multiple Verifiers: Das Expires 11 March 2027 [Page 64] Internet-Draft Attestation-Bound Execution Finality September 2026 CPU Verifier --------\ \ GPU Verifier ----------> composed trust result / DPU Verifier --------/ | v Candidate Act | finality Figure 74 Current RATS work is separately examining multiple-Verifier topologies. *RATS relevance:* composite and multi-Verifier Attestation Results can feed finality validation. *WIMSE relevance:* after platform trust is established, WIMSE identifies the software workload operating inside that trusted environment. FAQ 4. Does this require changes to accelerator hardware or instruction sets? *Question* Would an accelerator implementation need to be redesigned to support this architecture? *Answer* No. The proposed enforcement occurs after an application has formed a consequence-bearing operation; it does not alter tensor execution, instruction sets, matrix engines, or accelerator scheduling. The architecture separates: COMPUTATION tensor operation matrix multiplication inference model execution | v Candidate Act Das Expires 11 March 2027 [Page 65] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 75 from: AUTHORITY Candidate Act | validation | Finality Sink | external effect Figure 76 A deployment could therefore use an existing confidential accelerator unchanged. The enforcement component might instead reside in: confidential VM DPU SmartNIC host TEE kernel hypervisor API gateway service mesh destination service Figure 77 Chip vendors could nevertheless integrate the function more deeply if desired. For example, a future DPU could provide a protected finality- verification primitive, or an accelerator runtime could expose an attested binding between a model workload and Candidate Act digest. Those are implementation optimizations, not architectural requirements. *RATS relevance:* existing accelerator Evidence remains reusable. *WIMSE relevance:* workload-level identity remains independent of accelerator instruction-set design. Das Expires 11 March 2027 [Page 66] Internet-Draft Attestation-Bound Execution Finality September 2026 FAQ 5. Isn't WIMSE workload identity already enough to authorize the operation? *Question* If a workload possesses a valid WIMSE Workload Identity Token or Workload Identity Certificate, why does it need another authorization step? *Answer* Because identity and authority are distinct. The current WIMSE architecture itself makes this distinction explicitly: authenticating a workload establishes control of credentials but is not sufficient by itself to determine whether that workload may access a resource or perform an action. The authorization decision additionally considers the operation, resource, policy, and relevant security context. Execution finality extends that logic to the effectuation boundary. For example: WIT: workload = ai-agent-47 Figure 78 can authenticate the workload. But the following operations are not equivalent: read(database-A) Figure 79 delete(database-A) Figure 80 copy(database-A, external-domain-B) Figure 81 The proposed composition becomes: Das Expires 11 March 2027 [Page 67] Internet-Draft Attestation-Bound Execution Finality September 2026 WIMSE identity + Candidate Act + RATS trust state + policy | v act-specific decision | v Finality Sink Figure 82 Therefore, WIMSE answers primarily: which workload is presenting this credential, and can it prove possession? While execution finality asks: may this exact consequential operation become effective at this boundary under the current identity, trust, policy and context? *RATS relevance:* supplies trustworthy execution-state information. *WIMSE relevance:* supplies workload identity and proof-of-possession foundations. FAQ 6. Why isn't an OAuth access token or down-scoped transaction token sufficient? *Question* Why not mint a narrowly scoped OAuth token after the concrete request has been generated? *Answer* That can be a valid implementation mechanism. This architecture should not claim otherwise. An OAuth authorization server could issue a sufficiently narrow per- operation credential containing or referencing: Das Expires 11 March 2027 [Page 68] Internet-Draft Attestation-Bound Execution Finality September 2026 actor resource operation arguments audience expiration transaction identifier Figure 83 If the Resource Server verifies it against the exact operation, then such a token could implement part of execution finality. The architectural question is broader: what invariant must be preserved regardless of the authorization artifact chosen? The proposed invariant is: Candidate Act | | remains non-effective v act-bound authorization | v mandatory verification at consequence boundary | v external effect Figure 84 Therefore an OAuth Transaction Token, capability, COSE object, HTTP Message Signature, WIMSE proof token, or another mechanism may become a concrete encoding. The document intentionally separates the finality invariant from the credential format. *RATS relevance:* attestation state can contribute to the authorization inputs used when minting or validating such an artifact. *WIMSE relevance:* WIMSE workload credentials can identify the actor requesting the transaction-specific authority. Das Expires 11 March 2027 [Page 69] Internet-Draft Attestation-Bound Execution Finality September 2026 FAQ 7. Isn't the Execution Handle just another bearer token? *Question* If the validator returns an Execution Handle, an attacker could steal it and replay it. How is this different from an ordinary bearer credential? *Answer* The Execution Handle should not be defined as unrestricted bearer authority. It should be bound to security-relevant context. For example: EH = Sign { act_digest, workload_id, target, audience, transaction_id, nonce, expiry, policy_context, proof_key } Figure 85 A stolen EH should therefore fail when presented with: different Candidate Act different workload different target different proof key different transaction expired freshness state Figure 86 Where possible, implementations should use proof-of-possession rather than possession alone. Conceptually, possession of the EH does not equal authority. Instead: Das Expires 11 March 2027 [Page 70] Internet-Draft Attestation-Bound Execution Finality September 2026 EH + correct Candidate Act + correct presenter + correct target + fresh context = usable execution authority Figure 87 An implementation may omit a separate Execution Handle entirely and have the Finality Sink query the validator directly. The architecture depends on the binding, not on the existence of a new token. *RATS relevance:* attested keys or key-binding mechanisms can strengthen the identity of the presenter. *WIMSE relevance:* WIMSE credentials already bind workload identity to cryptographic key material and therefore provide useful proof-of- possession foundations. FAQ 8. Who creates the Candidate Act, and how is it canonicalized? *Question* If the AI runtime creates one representation but the destination interprets another representation, how can the authorization binding be trusted? *Answer* This is one of the most important protocol-design problems. The authorization must bind to the representation that determines the protected consequence. For an HTTP operation, security-relevant material might include: Das Expires 11 March 2027 [Page 71] Internet-Draft Attestation-Bound Execution Finality September 2026 method authority path selected headers body target resource Figure 88 For an RPC: service method arguments target Figure 89 For a cloud-control operation: operation resource ID tenant region parameters Figure 90 The document should therefore require an application-specific Candidate Act Canonicalization Profile. A generic formula might be: act_digest = HASH( profile_identifier || canonical_candidate_act ) Figure 91 The profile identifier prevents the same byte sequence from being interpreted under two incompatible canonicalization rules. Any security-relevant field that is interpreted by the Finality Sink must either: 1. be contained in the canonical Candidate Act; or Das Expires 11 March 2027 [Page 72] Internet-Draft Attestation-Bound Execution Finality September 2026 2. be independently constrained by the authorization context. Otherwise parameter substitution is possible. The Finality Sink is ultimately authoritative regarding which canonical representation corresponds to the consequence it performs. *RATS relevance:* RATS does not need to define HTTP, RPC, payment, or cloud-operation canonicalization. *WIMSE relevance:* WIMSE identifies the initiating workload; application profiles define the operation being authorized. FAQ 9. What technically makes a Candidate Act "non-effective"? *Question* Is "non-effective state" merely policy terminology? What prevents a compromised workload from bypassing validation and directly executing the operation? *Answer* The non-effective state must be enforced by architecture, not simply declared in metadata. For a protected consequence, every path capable of producing that consequence must pass a trusted enforcement boundary. For example: AI workload | Candidate Act | X--------------------> protected service | direct path blocked | v Finality Sink | v protected service Figure 92 Possible mechanisms include: Das Expires 11 March 2027 [Page 73] Internet-Draft Attestation-Bound Execution Finality September 2026 DPU-enforced egress kernel mediation hypervisor mediation API-gateway enforcement service-mesh enforcement database commit enforcement destination-side verification capability-required API TEE-mediated system call Figure 93 If an attacker can bypass the Finality Sink and cause the same protected consequence through another path, then technical non- effectiveness has not been achieved. That should be stated explicitly as a security requirement: for a consequence claimed to be protected by execution finality, there MUST NOT exist an unmediated effectuation path available to the protected workload. This is the strongest distinction between an execution-finality architecture and a system that merely generates audit evidence. *RATS relevance:* RATS establishes trust-related facts; it does not automatically create this topology. *WIMSE relevance:* WIMSE can authenticate workloads traversing the enforced path, but workload identity alone does not remove bypass paths. FAQ 10. How does the architecture prevent TOCTOU between authorization and execution? *Question* What prevents the operation from changing after it is validated but before the Finality Sink executes it? *Answer* The Finality Sink must verify the same security-relevant Candidate Act that was authorized. Suppose: Das Expires 11 March 2027 [Page 74] Internet-Draft Attestation-Bound Execution Finality September 2026 A = canonical Candidate Act H = HASH(A) Figure 94 The validator authorizes H. At finality: H' = HASH(received Candidate Act) Figure 95 The Sink requires: H' == H Figure 96 together with verification of the authorization evidence. Therefore: validation | v Act A | attacker changes amount | v Act A' | HASH(A') != authorized HASH(A) | v DENY Figure 97 For state-dependent operations, binding only the request may still be insufficient. The decision may need to include: Das Expires 11 March 2027 [Page 75] Internet-Draft Attestation-Bound Execution Finality September 2026 resource version transaction epoch policy version expected state sequence number Figure 98 or the Finality Sink may need to re-evaluate those conditions atomically with effectuation. The strongest implementation is therefore: verify, consume authorization, and effectuate within one trusted transactional boundary. *RATS relevance:* freshness and Attestation Result applicability remain relevant but are not substitutes for operation-level TOCTOU protection. *WIMSE relevance:* workload identity remains bound to the operation but does not itself guarantee immutability of operation parameters. FAQ 11. How are replay, duplication, and retry handled at hyperscale? *Question* Distributed systems legitimately retry requests. How can replay protection distinguish malicious replay from safe retry? *Answer* Replay resistance should not simply mean "reject the same bytes twice." The Finality Sink can use an idempotency or transaction model. For example: transaction_id = 7F29... act_digest = H(A) max_effects = 1 expiry = T Figure 99 The Sink maintains: (transaction_id, act_digest) -> state Das Expires 11 March 2027 [Page 76] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 100 with states such as: UNUSED IN_PROGRESS COMMITTED FAILED_RETRYABLE EXPIRED Figure 101 A network retry of a committed transaction can return the existing result without repeating the consequence. A different Candidate Act presented with the same transaction identifier is rejected. For operations legitimately allowing multiple effects, the authorization can specify: max_uses sequence range rate limit resource set Figure 102 The exact semantics remain application-specific. *RATS relevance:* RATS already treats freshness and result lifetime as important properties. RFC 9334 distinguishes generation, appraisal, operation, and expiry events. *WIMSE relevance:* workload authentication identifies who is retrying; finality state determines whether the consequence may occur again. FAQ 12. Would per-act verification destroy GPU or hyperscaler performance? *Question* Large inference clusters can issue enormous numbers of operations. Does execution finality place remote attestation or expensive cryptography on every request? *Answer* Das Expires 11 March 2027 [Page 77] Internet-Draft Attestation-Bound Execution Finality September 2026 No. The architecture should explicitly separate the cold path from the hot path. COLD PATH CPU/GPU/DPU Evidence | v attestation verification | v Attestation Result | v cached trust context Figure 103 Then: HOT PATH Candidate Act | digest | policy/context lookup | compact authorization | Finality Sink verification Figure 104 Expensive endorsement retrieval, certificate-chain processing, reference-value evaluation, and composite attestation need not be performed for every Candidate Act. Furthermore, not every AI output requires execution finality. A deployment might classify: Das Expires 11 March 2027 [Page 78] Internet-Draft Attestation-Bound Execution Finality September 2026 ordinary inference output -> no finality processing read-only query -> lightweight policy financial transfer -> finality protected production deployment -> finality protected network reconfiguration -> finality protected external message publication -> finality protected Figure 105 A DPU, SmartNIC, local gateway, or destination endpoint could verify compact proofs locally without another network round trip. Thus execution finality is intended to operate at semantic consequence boundaries, not tensor-operation, packet, or memory- operation granularity. *RATS relevance:* reusable Attestation Results make cold-path/hot- path separation possible. *WIMSE relevance:* short-lived workload credentials and proof-of- possession can also be reused across many individual authorized operations. FAQ 13. How does this work across multi-agent and multi-workload chains? *Question* In an agentic workflow, one workload may plan, another may transform arguments, another may broker the tool call, and a fourth may execute it. Which workload is actually authorized? *Answer* The architecture should not require the initial workload identity to be treated as authority for all descendants. Consider: Agent A | Planner B | Tool Broker C | Execution Service D Figure 106 Das Expires 11 March 2027 [Page 79] Internet-Draft Attestation-Bound Execution Finality September 2026 Several identities can contribute to the decision: initiating principal delegated subject Agent A workload identity Planner B identity Broker C identity Execution Service identity Figure 107 However, finality is associated with the concrete operation presented at the consequence boundary. For example: Agent A: "pay approved invoice" Planner B: selects supplier Broker C: constructs: amount = 8,430 currency = EUR destination = account-X Finality Sink: authorizes the concrete transaction Figure 108 The final authorization can carry or reference provenance from earlier workloads while remaining bound to the final Candidate Act. This avoids treating transitive authentication as transitive unlimited authority. *RATS relevance:* different components in the chain may themselves have separate attestation states or Verifiers. *WIMSE relevance:* this is strongly aligned with WIMSE because the working group addresses workload identity in multi-service and multi- system environments. Its current architecture is specifically concerned with workload-to-workload authentication and authorization in distributed environments. Das Expires 11 March 2027 [Page 80] Internet-Draft Attestation-Bound Execution Finality September 2026 Execution finality provides a possible terminal enforcement semantic: authenticated workload chain | v concrete Candidate Act | v act-specific authority | v Finality Sink Figure 109 FAQ 14. How is this different from current WIMSE authorization- evidence/Permit work? *Question* There is already an individual Internet-Draft describing Signed Authorization-Evidence Records for WIMSE-authorized AI agent actions. It cryptographically commits to canonical request bytes before dispatch. Isn't that the same mechanism? *Answer* This is a serious overlap question and should be addressed explicitly. The current authorization-evidence draft defines a signed Permit recording a pre-execution authorization decision, binds it to canonical request bytes, and uses a Closure Record to bind to the dispatched request digest. The current revision also describes composition with OAuth, HTTP Message Signatures, WIMSE identity, and transaction-token context. Therefore the proposed execution-finality draft should not claim novelty merely because it authorizes before dispatch, hashes the concrete request, or creates signed authorization evidence. Those mechanisms are already being discussed. The narrower proposed distinction is the architectural enforcement property: Permit/evidence exists does not equal external consequence is technically dependent on verification of that evidence. Das Expires 11 March 2027 [Page 81] Internet-Draft Attestation-Bound Execution Finality September 2026 Execution finality requires identifying an effectuation boundary and making successful verification load-bearing for the consequence: Candidate Act | authorization | PVE / Permit / other artifact | v FINALITY SINK | verification required | v External Effect Figure 110 If the destination may execute the request without verifying the required act-bound authority, the deployment does not satisfy the proposed execution-finality property. Accordingly, the existing WIMSE Permit could potentially be used as one PVE representation rather than treated as a competing mechanism. The proposed architecture should therefore ask whether existing WIMSE authorization evidence can become a required execution dependency at the destination or infrastructure effectuation boundary. That is a substantially more constructive standards relationship. *RATS relevance:* attestation context can become one input into issuance or validation of the Permit/finality artifact. *WIMSE relevance:* extremely direct; WIMSE credentials, workload identity, and existing authorization-evidence work can potentially provide several protocol components rather than being reinvented. FAQ 15. How is this different from current RATS Action Evidence composition work? *Question* RATS already has an individual draft on composing application-layer Action Evidence Packages with platform attestation. Why isn't Candidate Act plus attestation just the same idea? Das Expires 11 March 2027 [Page 82] Internet-Draft Attestation-Bound Execution Finality September 2026 *Answer* This is the other comparison the document should confront directly. The current RATS AEP composition work describes cryptographically binding application-layer action records and outcomes to platform Evidence so that Verifiers and Relying Parties can reason jointly about platform state and what an automated system reports it did. It includes action digests, outcome digests, authority references, freshness considerations, and substitution tests. That means the proposed draft should not position action evidence plus remote attestation as a new concept by itself. The strongest distinction is temporal and architectural. Action evidence can answer questions such as: what action was reported, under what authority, on what attested platform, and what outcome was recorded? Execution finality asks: could the protected external effect have happened without successful verification of the required authorization binding? This produces two different security properties. Evidence property: Action | v record / digest / attestation | v verifiable evidence Figure 111 Execution-finality property: Das Expires 11 March 2027 [Page 83] Internet-Draft Attestation-Bound Execution Finality September 2026 Candidate Act | NON-EFFECTIVE | v authorization + validation | v Finality Sink | mandatory verification | v EFFECT Figure 112 The current AEP draft itself notes that a reported outcome remains an application-layer claim unless independently observable effect evidence exists, and that platform binding does not by itself prove the truth of the external effect. This gives the execution-finality proposal a useful boundary: evidence about an action is not necessarily the same security property as technical dependency of the action upon authorization. The two could also be composed: Das Expires 11 March 2027 [Page 84] Internet-Draft Attestation-Bound Execution Finality September 2026 RATS | platform Evidence | Attestation Result | v Candidate Act | validation | v Finality Sink | v External Effect | v AEP | auditable evidence Figure 113 This is potentially stronger than trying to replace the AEP work. *RATS relevance:* RATS establishes and composes trustworthy evidence about execution environments and increasingly about richer attestation contexts. *WIMSE relevance:* WIMSE identifies and authenticates the workloads participating in the action chain. *Execution-finality contribution:* defines the protected transition from a proposed operation to an externally effective operation and requires the authorization state to be load-bearing at that transition. FAQ 16. Does every CUDA kernel invocation need an Execution Handle? *Question* If GPUs are involved, does each individual kernel launch require cryptographic authorization? *Answer* Das Expires 11 March 2027 [Page 85] Internet-Draft Attestation-Bound Execution Finality September 2026 No. Execution finality is intended for consequence-bearing operations, not every computational instruction. GPU arithmetic, tensor operations, kernel launches, memory-local transformations, and inference steps can occur normally. The relevant point is the transition from computation to an externally consequential operation: GPU computation | | no finality check required v Model inference | | generates proposed external operation v Candidate Act | v Execution-Finality Validation | v External API / Storage / Control / Transaction Effect Figure 114 The architecture therefore does not require cryptographic authorization of every matrix multiplication or kernel execution. *RATS relevance:* GPU or accelerator Evidence remains an input to the trust plane and is unaffected by kernel-level execution. FAQ 17. What stops a compromised host from bypassing the Finality Sink? *Question* If the workload's host is itself compromised, could it simply call the protected target directly and skip the Finality Sink? *Answer* Nothing in a portable software library can guarantee non- bypassability if the protected target remains reachable through another uncontrolled path. Production deployment therefore requires the effectuation topology itself to enforce: Das Expires 11 March 2027 [Page 86] Internet-Draft Attestation-Bound Execution Finality September 2026 Workload | v Protected Finality Sink | v Target Figure 115 rather than: +--> Finality Sink --> Target Workload ----+ +--------------------> Target Figure 116 If an alternate unprotected route exists, the finality property can be bypassed. For GPU or accelerator integration, establishing this non-bypassability is a platform-specific engineering requirement, not a property the protocol logic can supply by itself. Where in a GPU deployment the Finality Sink should actually sit is intentionally left location-neutral. Depending on the system architecture, it could be implemented at a protected GPU-management boundary, a confidential-VM boundary, a DPU, a SmartNIC, an API gateway, a service-mesh enforcement point, a cloud control-plane component, a protected storage interface, a transaction service, or another non-bypassable boundary where an operation first becomes externally effective. The accompanying reference implementation (Section 34.8) uses an HTTP gateway because it provides a simple, independently testable effectuation boundary; this does not claim that the reference code is already embedded inside a commercial GPU, DPU, or SmartNIC. *RATS relevance:* platform Evidence can inform where a non-bypassable boundary can credibly be established, but RATS does not itself guarantee topology-level non-bypassability. FAQ 18. Could the Finality Sink or Execution-Finality Validator run inside GPU firmware, a DPU, SmartNIC, or a confidential VM? *Question* Is the architecture restricted to software gateways, or could the enforcement components be pushed into protected hardware? Das Expires 11 March 2027 [Page 87] Internet-Draft Attestation-Bound Execution Finality September 2026 *Answer* Conceptually yes, where appropriate platform primitives exist. The architecture is not restricted to software gateways. A future implementation could place validation or finality functionality in accelerator firmware, protected microcontrollers, GPU security processors, hardware-rooted enforcement domains, DPUs, SmartNICs, TEEs, or other protected hardware boundaries. The current reference code does not claim that such integration has been completed. Running the Execution-Finality Validator itself inside a confidential VM or TEE could similarly strengthen protection of authorization policy, signing keys, workload context, sensitive transaction data, and the authorization decision. The architecture does not prescribe where the EFV must execute; a hardware-rooted EFV is one possible production deployment, not a requirement of the minimal profile. *RATS relevance:* attested execution of the EFV or Finality Sink would itself be a candidate for Evidence and appraisal under the RATS architecture. FAQ 19. What if the Execution-Finality Validator itself is compromised? *Question* The EFV signs execution authority. What happens if that component is compromised? *Answer* Then the Validator could potentially issue unauthorized Execution Handles. The EFV therefore becomes a security-critical authorization component in its own right, distinct from the workload it authorizes. A production implementation should consider protected signing keys, HSM/KMS-backed keys, policy isolation, measured or attested EFV execution, separation of duties, short-lived authority, auditability, key rotation, rate controls, and independent policy verification. The architecture does not eliminate the need to protect the authorization authority itself. *RATS relevance:* the EFV's own execution environment can itself be a Verifier target, feeding an Attestation Result that a Relying Party uses when deciding whether to trust handles the EFV issues. FAQ 20. Why use separate EAT-signing and Execution-Handle-signing keys? *Question* Das Expires 11 March 2027 [Page 88] Internet-Draft Attestation-Bound Execution Finality September 2026 Could the same key that signs the EAT also sign the Execution Handle? *Answer* The two keys represent different trust functions. The EAT-signing key establishes claims about the workload or environment, while the EFV signing key establishes authorization for a specific operation. Keeping the keys separate prevents the attestation credential itself from being treated as execution authority: EAT key | v "This environment has these properties" EFV key | v "This exact act is authorized under this context" Figure 117 The reference implementation (Section "Implemented Components") issues Execution Handles from a signing key distinct from the Attester key for exactly this reason: possession of a valid EAT alone cannot be presented to the gateway as execution authority. FAQ 21. What happens with multiple Finality Sink replicas? *Question* The reference implementation demonstrates atomic replay protection using local SQLite. How does that generalize to a horizontally scaled deployment? *Answer* Das Expires 11 March 2027 [Page 89] Internet-Draft Attestation-Bound Execution Finality September 2026 A horizontally scaled deployment cannot safely rely on independent local replay databases if multiple gateway instances can commit the same consequence. Production deployment would require shared or distributed state capable of preserving the relevant single-use or transaction semantics. Potential designs depend on the target environment and could include strongly consistent transactional stores, partitioned nonce ownership, consensus-backed state, target- system conditional writes, or target-native idempotency mechanisms combined with finality verification. The reference implementation intentionally does not claim to solve distributed consensus; it demonstrates the single-node invariant that a production distributed replay store must preserve. *RATS relevance:* orthogonal to trust establishment; this is a property of the Finality Sink's transaction and replay-state design rather than of attestation appraisal. FAQ 22. How does this apply to streaming AI output and batched GPU operations? *Question* Does every generated token need a Finality Handle, and how would batched operations be authorized? *Answer* Not every token needs a Finality Handle. The system can distinguish model output generation from a proposed consequential act derived from that output. For streaming or agentic systems, a Candidate Act can be created when the workload proposes a consequential operation, such as invoking an external tool, committing a database mutation, issuing a cloud-control command, sending a payment, modifying infrastructure, or sending externally consequential network traffic; the exact granularity remains deployment-specific. The Candidate Act abstraction can similarly represent either one individual operation or an explicitly defined batch, provided the authorization semantics are unambiguous. If a batch is authorized as a unit, the digest must bind the security-relevant contents of that batch, and the Finality Sink must verify the same batch semantics before effectuation. FAQ 23. What happens if GPU state changes after attestation? *Question* Das Expires 11 March 2027 [Page 90] Internet-Draft Attestation-Bound Execution Finality September 2026 An Attestation Result may be reused across several Candidate Acts. What if the underlying device or configuration state changes in the meantime? *Answer* That becomes a freshness and trust-continuity problem, not an execution-finality problem as such. Possible platform-specific responses include shorter attestation validity, runtime measurements, epoch binding, configuration-version binding, device reset detection, revocation, periodic re-attestation, or hardware-provided continuity mechanisms. Execution finality does not replace those mechanisms; it can incorporate their resulting trust state into the act-specific authorization decision. *RATS relevance:* RFC 9334 freshness and result-lifetime concepts govern whether a cached Attestation Result remains an acceptable input; execution finality consumes that determination rather than redefining it. FAQ 24. Why isn't normal API validation at the target enough? *Question* Most services already validate incoming requests. Why introduce a separate finality architecture? *Answer* Ordinary target-side validation may be enough for some systems. Execution finality becomes useful where a system needs an explicit cryptographic relationship among the attested workload, the authorization decision, the exact proposed act, and the actual act reaching the effectuation boundary. The architecture is therefore most relevant where the separation between trusted computation and consequential authority matters, rather than as a universal replacement for target-side input validation. FAQ 25. Why is the reference implementation's protected effect stored in SQLite instead of executing a real GPU, cloud, or payment action? *Question* The reference implementation commits to a local SQLite effects table rather than a live payment or cloud operation. Why? *Answer* Das Expires 11 March 2027 [Page 91] Internet-Draft Attestation-Bound Execution Finality September 2026 This isolates and demonstrates the finality property without introducing unrelated production-system complexity. The protected effect in the reference implementation (Section 34.8) is an atomic database commit, which makes it possible to test that valid authorization produces exactly one effect, replay produces no second effect, and a modified operation produces no effect, without claiming production payment, cloud, or accelerator integration. FAQ 26. What would be required for a genuine NVIDIA or accelerator integration? *Question* What would it take to move from the portable reference implementation to a genuine integration with NVIDIA or other accelerator platforms? *Answer* The protocol logic alone is not enough. A production accelerator integration, whether with NVIDIA GPUs or another vendor's platform, would need platform-specific work including connection to actual accelerator attestation evidence, validation of the relevant attestation profile (for example a confidential-GPU Attestation Result profile such as [TDX-CGPU-EAR], or a publicly documented accelerator attestation stack such as NVIDIA's Attestation Suite, e.g. NRAS, the RIM Service, and the OCSP Service [NVIDIA-ATTESTATION]), device and workload identity binding, secure EFV key custody, protected control paths, placement of the Finality Sink, proof that consequential operations cannot bypass that Sink, distributed replay and transaction state, hardware reset and epoch handling, lifecycle and revocation handling, performance characterization, fault analysis, threat modeling, fuzzing, penetration testing, and independent security review. The current repository is intended to make the execution-finality protocol relationship executable and inspectable before such vendor- specific integration, including any NVIDIA or other accelerator- vendor integration, is attempted. No such integration has been performed or claimed. *Disclaimer:* NVIDIA is referenced in this document only as an informative, illustrative example, offered because the architecture's consequence-bearing-operation model is highly relevant to NVIDIA's published GPU and confidential-computing attestation tooling and is therefore easier to reason about concretely with a real, publicly documented stack. This reference is not an endorsement of, by, or affiliation with NVIDIA Corporation, is not a claim of any NVIDIA review, adoption, partnership, or integration, and does not make the Das Expires 11 March 2027 [Page 92] Internet-Draft Attestation-Bound Execution Finality September 2026 architecture NVIDIA-specific; the architecture remains vendor-neutral and applies equally to other accelerator, DPU, SmartNIC, and confidential-computing vendors and platforms. Summary: Relationship Between RATS, WIMSE, and Execution Finality The three layers can be summarized as follows: Das Expires 11 March 2027 [Page 93] Internet-Draft Attestation-Bound Execution Finality September 2026 +--------------------------------------------------+ | RATS | | | | What can be established about the platform, | | environment, component, or Attester? | | | | Evidence -> Verifier -> Attestation Result | +--------------------------+-----------------------+ | v +--------------------------------------------------+ | WIMSE | | | | Which workload is participating? | | Can it prove possession of its identity key? | | What trust domain does it belong to? | | | | Workload Identifier | | WIT / WIC | | workload-to-workload authentication | +--------------------------+-----------------------+ | v +--------------------------------------------------+ | EXECUTION FINALITY | | | | What exact operation is proposed? | | Is it authorized under the current identity, | | attestation, policy and context? | | | | Can it acquire external effect without passing | | the designated enforcement boundary? | | | | Candidate Act | | | | | v | | act-bound validation | | | | | v | | Finality Sink | | | | | v | | External Effect | +--------------------------------------------------+ Figure 118 Das Expires 11 March 2027 [Page 94] Internet-Draft Attestation-Bound Execution Finality September 2026 The architecture therefore does not propose RATS versus execution finality, or WIMSE versus execution finality. It proposes the possible composition: RATS "Can this execution context be trusted?" | v WIMSE "Which workload is acting?" | v ACT-SPECIFIC AUTHORIZATION "Is this exact operation permitted?" | v EXECUTION FINALITY "Has the required authorization become technically load-bearing before consequence?" | v EXTERNAL EFFECT Figure 119 The core architectural invariant is end-to-end correspondence between the operation evaluated by the authorization function and the operation presented for effectuation. Environment appraisal and workload authentication are inputs to that decision, not substitutes for the act-specific decision. For protected consequence classes, the Candidate Act remains non- effective until evidence authorizing its security-relevant content is verified at the boundary where the protected effect would be committed. Author's Address Sangam Kumar Das Independent Inventor and Researcher Balasore 756001 Odisha India Email: info@sangamdas.com Das Expires 11 March 2027 [Page 95]