Network Working Group S. Das Internet-Draft Independent Inventor and Researcher Intended status: Informational September 2026 Expires: 8 March 2027 Attestation-Bound Execution Finality for AI Accelerators and Confidential Workloads draft-das-rats-attestation-bnd-execution-finality-00 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. 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. Successful attestation of the environment that generated such an operation does not, by itself, require that every subsequently generated operation acquire external effect. 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: trusted computation is not, by itself, act-specific authority. Das Expires 8 March 2027 [Page 1] Internet-Draft Attestation-Bound Execution Finality September 2026 The architecture is intended to complement, rather than replace, Remote ATtestation procedureS (RATS), Entity Attestation Token (EAT) [EAT], 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." This Internet-Draft will expire on 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. From Computational Trust to Consequential Authority . . . 7 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Replacing RATS . . . . . . . . . . . . . . . . . . . . . 10 4.2. Declaring Attestation Insufficient . . . . . . . . . . . 10 4.3. Replacing OAuth or Workload Identity . . . . . . . . . . 10 4.4. Mandating Hardware . . . . . . . . . . . . . . . . . . . 10 Das Expires 8 March 2027 [Page 2] Internet-Draft Attestation-Bound Execution Finality September 2026 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Candidate Act . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Non-Effective State . . . . . . . . . . . . . . . . . . . 11 5.3. Execution-Finality Validator . . . . . . . . . . . . . . 12 5.4. Protected Validation Evidence . . . . . . . . . . . . . . 13 5.5. Execution Handle . . . . . . . . . . . . . . . . . . . . 13 5.6. Finality Sink . . . . . . . . . . . . . . . . . . . . . . 13 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Binding Attestation to a Candidate Act . . . . . . . . . . . 16 8. Why Attestation Alone Is Not the Binding . . . . . . . . . . 17 9. Relationship to the RATS Architecture . . . . . . . . . . . . 19 10. Composite CPU and Confidential-Accelerator Environments . . . 20 11. AI Accelerator Example . . . . . . . . . . . . . . . . . . . 21 12. Hyperscale Deployment . . . . . . . . . . . . . . . . . . . . 22 13. DPU and SmartNIC Deployment . . . . . . . . . . . . . . . . . 24 14. Network Fabric Considerations . . . . . . . . . . . . . . . . 25 15. Relationship to Workload Identity . . . . . . . . . . . . . . 25 16. Separation of Identity, Trust, Authority, and Finality . . . 26 16.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 26 16.2. Trust . . . . . . . . . . . . . . . . . . . . . . . . . 26 16.3. Authority . . . . . . . . . . . . . . . . . . . . . . . 27 16.4. Finality . . . . . . . . . . . . . . . . . . . . . . . . 27 17. Candidate Act Canonicalization . . . . . . . . . . . . . . . 27 18. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 28 19. Replay Resistance . . . . . . . . . . . . . . . . . . . . . . 28 20. Non-Bearer Properties . . . . . . . . . . . . . . . . . . . . 29 21. Finality Sink Placement . . . . . . . . . . . . . . . . . . . 30 22. Finality Sink Is Not Necessarily a New Appliance . . . . . . 30 23. Hot-Path and Cold-Path Processing . . . . . . . . . . . . . . 31 24. Legacy Deployment . . . . . . . . . . . . . . . . . . . . . . 32 25. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 33 25.1. Validation Failure . . . . . . . . . . . . . . . . . . . 33 25.2. Missing Attestation Context . . . . . . . . . . . . . . 33 25.3. Expired Validation Evidence . . . . . . . . . . . . . . 33 25.4. Parameter Mutation . . . . . . . . . . . . . . . . . . . 33 25.5. Finality Sink Unavailable . . . . . . . . . . . . . . . 33 26. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 34 27. Security Considerations . . . . . . . . . . . . . . . . . . . 34 28. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 29. Example: Confidential AI Inference in a Hyperscaler . . . . . 36 30. Example: DPU-Mediated AI Egress . . . . . . . . . . . . . . . 37 31. Example: Multi-Workload Agent Chain . . . . . . . . . . . . . 38 32. Interoperability Requirements . . . . . . . . . . . . . . . . 39 33. Potential Protocol Flow . . . . . . . . . . . . . . . . . . . 40 34. Why This Matters for AI Infrastructure . . . . . . . . . . . 41 35. Operational Considerations . . . . . . . . . . . . . . . . . 42 36. Discussion of Latency . . . . . . . . . . . . . . . . . . . . 42 37. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 43 Das Expires 8 March 2027 [Page 3] Internet-Draft Attestation-Bound Execution Finality September 2026 38. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 39. Normative References . . . . . . . . . . . . . . . . . . . . 44 40. Informative References . . . . . . . . . . . . . . . . . . . 44 Appendix A. Architectural Summary . . . . . . . . . . . . . . . 44 Appendix B. Concise Statement for Discussion . . . . . . . . . . 46 Appendix C. Technical FAQ and Anticipated Engineering Questions . . . . . . . . . . . . . . . . . . . . . . . . 46 FAQ 1. Isn't this already what a RATS Relying Party does? . . 46 FAQ 2. Is this simply AR4SI applied to individual requests? . 48 FAQ 3. How does this interact with composite CPU, CVM, GPU, and accelerator attestation? . . . . . . . . . . . . . . . 50 FAQ 4. Does this require changes to GPUs, CPUs, tensor cores, or accelerator instruction sets? . . . . . . . . . . . . . 52 FAQ 5. Isn't WIMSE workload identity already enough to authorize the operation? . . . . . . . . . . . . . . . . . . . . 54 FAQ 6. Why isn't an OAuth access token or down-scoped transaction token sufficient? . . . . . . . . . . . . . 55 FAQ 7. Isn't the Execution Handle just another bearer token? . . . . . . . . . . . . . . . . . . . . . . . . 57 FAQ 8. Who creates the Candidate Act, and how is it canonicalized? . . . . . . . . . . . . . . . . . . . . 58 FAQ 9. What technically makes a Candidate Act "non-effective"? . . . . . . . . . . . . . . . . . . . 60 FAQ 10. How does the architecture prevent TOCTOU between authorization and execution? . . . . . . . . . . . . . 61 FAQ 11. How are replay, duplication, and retry handled at hyperscale? . . . . . . . . . . . . . . . . . . . . . . 63 FAQ 12. Would per-act verification destroy GPU or hyperscaler performance? . . . . . . . . . . . . . . . . . . . . . 64 FAQ 13. How does this work across multi-agent and multi-workload chains? . . . . . . . . . . . . . . . . . . . . . . . . 66 FAQ 14. How is this different from current WIMSE authorization-evidence/Permit work? . . . . . . . . . . 68 FAQ 15. How is this different from current RATS Action Evidence composition work? . . . . . . . . . . . . . . . . . . . 69 Summary: Relationship Between RATS, WIMSE, and Execution Finality . . . . . . . . . . . . . . . . . . . . . . . 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 74 1. Introduction Modern computing systems increasingly combine heterogeneous execution components. A single workload may involve: * a CPU; Das Expires 8 March 2027 [Page 4] Internet-Draft Attestation-Bound Execution Finality September 2026 * 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. 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: Das Expires 8 March 2027 [Page 5] Internet-Draft Attestation-Bound Execution Finality September 2026 POST /payment destination = account-B amount = 50000 currency = USD Figure 1 Attestation may establish important properties of the CPU, GPU, confidential VM, firmware, software measurements, or other execution components. Those properties do not necessarily mean that the specific operation above should automatically be executed. 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) Figure 5 or: open_valve(device-D, 80-percent) Figure 6 or: transfer_control(workload-A, workload-B) Das Expires 8 March 2027 [Page 6] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 7 The distinction is not between trusted and untrusted computation. The environment may be fully attested and operating exactly as intended. The distinction is between: 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. 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. Das Expires 8 March 2027 [Page 7] Internet-Draft Attestation-Bound Execution Finality September 2026 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; * 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. Das Expires 8 March 2027 [Page 8] Internet-Draft Attestation-Bound Execution Finality September 2026 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. This document does not specify a particular model architecture. It does not specify GPU instruction sets, tensor-processing semantics, accelerator scheduling, optical networking, Ethernet, InfiniBand, NVLink, or other transport technology. It does not replace remote attestation. It does not define a universal authorization policy. It does not require that validation occur in a hardware TEE. It does not require that the Finality Sink be colocated with the workload. Das Expires 8 March 2027 [Page 9] Internet-Draft Attestation-Bound Execution Finality September 2026 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; * confidential VM; * DPU; * SmartNIC; Das Expires 8 March 2027 [Page 10] Internet-Draft Attestation-Bound Execution Finality September 2026 * 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; * transformed; * queued; * simulated; Das Expires 8 March 2027 [Page 11] Internet-Draft Attestation-Bound Execution Finality September 2026 * 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; * time; * nonce; * sequence state; Das Expires 8 March 2027 [Page 12] Internet-Draft Attestation-Bound Execution Finality September 2026 * 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 * 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. Das Expires 8 March 2027 [Page 13] Internet-Draft Attestation-Bound Execution Finality September 2026 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 8 March 2027 [Page 14] 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 8 March 2027 [Page 15] 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. Merely possessing the Candidate Act is insufficient. Merely executing the computation that generated the Candidate Act is insufficient. Where required by the deployment, merely possessing an Attestation Result is also insufficient to authorize materially different acts. 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 8 March 2027 [Page 16] 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 8 March 2027 [Page 17] 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 8 March 2027 [Page 18] 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 8 March 2027 [Page 19] 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 8 March 2027 [Page 20] 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 8 March 2027 [Page 21] 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 8 March 2027 [Page 22] 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 8 March 2027 [Page 23] 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 8 March 2027 [Page 24] 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 8 March 2027 [Page 25] 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 valid workload identity alone does not necessarily imply unlimited authority to perform every operation accessible to that workload. 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 8 March 2027 [Page 26] 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 8 March 2027 [Page 27] 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 8 March 2027 [Page 28] 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 8 March 2027 [Page 29] 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 8 March 2027 [Page 30] 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 8 March 2027 [Page 31] 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 8 March 2027 [Page 32] 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 8 March 2027 [Page 33] 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 8 March 2027 [Page 34] 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 8 March 2027 [Page 35] 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 8 March 2027 [Page 36] 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 8 March 2027 [Page 37] 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 8 March 2027 [Page 38] 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 8 March 2027 [Page 39] 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 8 March 2027 [Page 40] 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. Why This Matters for AI Infrastructure Large AI systems increasingly transform model outputs into executable operations. At the same time, infrastructure is moving toward stronger hardware- rooted trust: CPU attestation GPU attestation confidential VMs accelerator isolation DPU isolation workload identity service identity Figure 55 These mechanisms strengthen confidence in where computation occurs and which workload participates. Execution finality adds a complementary invariant: a consequential output remains non-effective until the authorization required for that exact operation is established at its consequence boundary. Figure 56 Das Expires 8 March 2027 [Page 41] Internet-Draft Attestation-Bound Execution Finality September 2026 This separates computational capability from consequential authority. In short: computation is not authority. 35. 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. Instead, enforcement can occur at semantically meaningful boundaries such as: create delete transfer deploy publish send commit open release modify authorize Figure 57 This permits high-throughput accelerator and network fabrics to operate normally while protected consequences receive stronger authorization semantics. 36. 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. Das Expires 8 March 2027 [Page 42] Internet-Draft Attestation-Bound Execution Finality September 2026 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. 37. Open Questions The following questions are intentionally left open for IETF discussion: 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? Das Expires 8 March 2027 [Page 43] Internet-Draft Attestation-Bound Execution Finality September 2026 38. 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. 39. Normative References [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . 40. Informative References [EAT] IETF EAT Work, "The Entity Attestation Token (EAT)". IETF Entity Attestation Token work. [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. Appendix A. Architectural Summary The complete transition can be summarized as: TRUST PLANE Evidence / Attestation | v Verifier | v Attestation Result | | v COMPUTE PLANE Das Expires 8 March 2027 [Page 44] Internet-Draft Attestation-Bound Execution Finality September 2026 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 | v FINALITY PLANE Finality Sink | v EXTERNAL EFFECT Figure 58 The principal distinction is: Das Expires 8 March 2027 [Page 45] Internet-Draft Attestation-Bound Execution Finality September 2026 ATTESТED does not necessarily mean AUTHORIZED FOR EVERY ACT COMPUTED does not necessarily mean AUTHORIZED AUTHORIZED does not become consequential until the required finality boundary accepts the authorization. Figure 59 Appendix B. Concise Statement for Discussion Remote attestation can tell a relying party important facts about the CPU, confidential VM, GPU, accelerator, firmware, software, or workload involved in computation. Workload identity can identify the workload making a request. Neither property requires a system to treat every future operation produced by that workload as automatically effective. This document explores a narrow interoperability question: Can an Attestation Result and workload identity be cryptographically bound to one concrete consequential operation, while that operation remains non-effective, so that a destination-side or infrastructure- side Finality Sink can verify the binding before permitting the external effect? 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. FAQ 1. Isn't this already what a RATS Relying Party does? *Question* Das Expires 8 March 2027 [Page 46] Internet-Draft Attestation-Bound Execution Finality September 2026 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 60 The proposed execution-finality composition adds: Das Expires 8 March 2027 [Page 47] 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 61 The proposed property is therefore not simply "make an authorization decision" but: the protected external effect cannot occur through the protected path unless the authorization decision corresponds to this specific Candidate Act. 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 8 March 2027 [Page 48] 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 addresses a more granular operation: secure interaction permitted does not equal every subsequent operation permitted. 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 62 followed later by: DELETE /instances/production-47 Figure 63 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 64 and independently: Das Expires 8 March 2027 [Page 49] Internet-Draft Attestation-Bound Execution Finality September 2026 same trust context | +------------------+ | Candidate Act B | different decision Figure 65 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 8 March 2027 [Page 50] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 66 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 67 The important point is that the same successfully attested GPU environment can generate many different operations. 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 68 The attested environment can remain identical. The authorization decision need not. The current RATS TDX+C-GPU work from Microsoft, Intel, and NVIDIA [TDX-CGPU-EAR] is specifically concerned with establishing trust in a combined confidential VM and confidential NVIDIA GPU environment. That makes its Attestation Result a particularly natural input to the proposed architecture. The architecture also accommodates multiple Verifiers: Das Expires 8 March 2027 [Page 51] Internet-Draft Attestation-Bound Execution Finality September 2026 CPU Verifier --------\ \ GPU Verifier ----------> composed trust result / DPU Verifier --------/ | v Candidate Act | finality Figure 69 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 GPUs, CPUs, tensor cores, or accelerator instruction sets? *Question* Would NVIDIA, AMD, Intel, Arm, or other chip vendors need to redesign accelerator hardware to implement this mechanism? *Answer* No architectural requirement in this document requires modifying tensor cores, GPU instruction sets, matrix engines, or accelerator scheduling. The architecture separates: COMPUTATION tensor operation matrix multiplication inference model execution | v Candidate Act Das Expires 8 March 2027 [Page 52] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 70 from: AUTHORITY Candidate Act | validation | Finality Sink | external effect Figure 71 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 72 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 8 March 2027 [Page 53] 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 73 can authenticate the workload. But the following operations are not equivalent: read(database-A) Figure 74 delete(database-A) Figure 75 copy(database-A, external-domain-B) Figure 76 The proposed composition becomes: Das Expires 8 March 2027 [Page 54] Internet-Draft Attestation-Bound Execution Finality September 2026 WIMSE identity + Candidate Act + RATS trust state + policy | v act-specific decision | v Finality Sink Figure 77 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 8 March 2027 [Page 55] Internet-Draft Attestation-Bound Execution Finality September 2026 actor resource operation arguments audience expiration transaction identifier Figure 78 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 79 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 8 March 2027 [Page 56] 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 80 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 81 Where possible, implementations should use proof-of-possession rather than possession alone. Conceptually, possession of the EH does not equal authority. Instead: Das Expires 8 March 2027 [Page 57] Internet-Draft Attestation-Bound Execution Finality September 2026 EH + correct Candidate Act + correct presenter + correct target + fresh context = usable execution authority Figure 82 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 8 March 2027 [Page 58] Internet-Draft Attestation-Bound Execution Finality September 2026 method authority path selected headers body target resource Figure 83 For an RPC: service method arguments target Figure 84 For a cloud-control operation: operation resource ID tenant region parameters Figure 85 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 86 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 8 March 2027 [Page 59] 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 87 Possible mechanisms include: Das Expires 8 March 2027 [Page 60] 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 88 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 8 March 2027 [Page 61] Internet-Draft Attestation-Bound Execution Finality September 2026 A = canonical Candidate Act H = HASH(A) Figure 89 The validator authorizes H. At finality: H' = HASH(received Candidate Act) Figure 90 The Sink requires: H' == H Figure 91 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 92 For state-dependent operations, binding only the request may still be insufficient. The decision may need to include: Das Expires 8 March 2027 [Page 62] Internet-Draft Attestation-Bound Execution Finality September 2026 resource version transaction epoch policy version expected state sequence number Figure 93 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 94 The Sink maintains: (transaction_id, act_digest) -> state Das Expires 8 March 2027 [Page 63] Internet-Draft Attestation-Bound Execution Finality September 2026 Figure 95 with states such as: UNUSED IN_PROGRESS COMMITTED FAILED_RETRYABLE EXPIRED Figure 96 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 97 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 8 March 2027 [Page 64] 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 98 Then: HOT PATH Candidate Act | digest | policy/context lookup | compact authorization | Finality Sink verification Figure 99 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 8 March 2027 [Page 65] 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 100 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 101 Das Expires 8 March 2027 [Page 66] 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 102 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 103 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 8 March 2027 [Page 67] 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 104 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 8 March 2027 [Page 68] 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 105 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 8 March 2027 [Page 69] 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 106 Execution-finality property: Das Expires 8 March 2027 [Page 70] Internet-Draft Attestation-Bound Execution Finality September 2026 Candidate Act | NON-EFFECTIVE | v authorization + validation | v Finality Sink | mandatory verification | v EFFECT Figure 107 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 8 March 2027 [Page 71] 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 108 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. Summary: Relationship Between RATS, WIMSE, and Execution Finality The three layers can be summarized as follows: Das Expires 8 March 2027 [Page 72] 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 109 Das Expires 8 March 2027 [Page 73] 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 110 The core architectural invariant is: successful computation does not itself constitute authority, successful authentication does not itself constitute authorization, and successful attestation does not itself require that every subsequently generated operation become externally effective. For protected consequence classes, the Candidate Act remains non- effective until the authorization required for that concrete act is verified at the boundary where the act would first acquire external effect. Author's Address Sangam Kumar Das Independent Inventor and Researcher Balasore 756001 Odisha India Email: info@sangamdas.com Das Expires 8 March 2027 [Page 74]