Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure
draft-das-rats-attestation-bnd-execution-finality-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-08 (Latest revision 2026-09-10) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Github - Reference implementation, tests, benchmarks, and deployment materials
Report- The 85.B2 Challenge: Does This Earlier Disclosed AI-Agent Architecture is Similar to Meta Muse/Sentinel? |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-rats-attestation-bnd-execution-finality-04
Network Working Group S. Das
Internet-Draft Independent Inventor and Researcher
Intended status: Informational 11 September 2026
Expires: 15 March 2027
Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU,
SmartNIC, and Confidential-Computing Infrastructure
draft-das-rats-attestation-bnd-execution-finality-04
Abstract
Remote attestation can establish that a CPU, confidential virtual
machine, GPU, AI accelerator, DPU, or SmartNIC is running expected
firmware and software in an expected configuration. However, an
acceptable Attestation Result describes the execution environment,
not the operations it later emits; it remains the same whether
subsequent workload outputs arise from expected logic, prompt
injection, or model error. As AI workloads become agentic and move
onto confidential accelerator infrastructure, they emit high-
consequence operations, such as financial transfers, cloud-control
mutations, database deletions, and external API invocations, where
platform trustworthiness alone cannot determine whether a concrete
operation is authorized to take effect. OAuth access tokens,
transaction tokens, and workload credentials do not close this gap on
their own: they typically authorize by scope and by possession of a
credential rather than by the exact content of one operation, and
they do not require that the protected effect be unreachable except
through a verifying boundary.
This document describes an attestation-bound execution-finality
architecture that bridges platform appraisal and consequence-bearing
authorization. A consequential operation originates in a non-
effective state as a Candidate Act. An Execution-Finality Validator
evaluates the act's security-relevant arguments together with the
platform's Attestation Result, workload identity, and policy, and
issues an act-bound, single-use, non-bearer Execution Handle. A
Finality Sink verifies that handle at the non-bypassable boundary
where the operation would first acquire external effect, so that an
authorized act cannot be swapped, mutated, or replayed.
The architecture requires no changes to silicon, microcode, firmware,
drivers, or accelerator programming models, and it separates
concerns: platforms such as NVIDIA confidential-computing GPUs and
BlueField DPUs, Arm Confidential Compute Architecture (CCA), AMD SEV-
SNP, and Intel TDX supply environment appraisal on the cold path,
while enforcement is placed at the gateway, service-mesh, DPU or
SmartNIC, network, or storage boundary. On the hot path,
Das Expires 15 March 2027 [Page 1]
Internet-Draft Attestation-Bound Execution Finality September 2026
verification uses local cryptographic bindings and single-use checks
rather than repeated attestation round trips. The document discusses
its relationship to RATS, WIMSE, OAuth, and related IETF work, and
its engineering FAQ addresses platform layering, DPU visibility under
end-to-end encryption, tail latency, and other anticipated critical
questions. It is intentionally long because it is explanatory rather
than a protocol specification.
The architecture is implemented, not only described. An executable
reference implementation (GitHub: reference implementation, tests,
benchmarks, and deployment materials, https://github.com/sangmdas/
Execution-Finality-for-GPU-AI-Accelerators-and-Confidential-
Workloads) demonstrates act binding, single-use enforcement, and
replay rejection in running code. It uses a software-only attester;
it has not been run on any vendor's confidential-computing hardware
and does not consume any vendor-issued attestation token, and vendor
platforms are discussed on the basis of public documentation only.
This document is vendor-neutral, neither claims nor implies review,
adoption, endorsement, or affiliation by any named vendor, and
complements rather than replaces existing attestation, workload-
identity, and 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 15 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
Das Expires 15 March 2027 [Page 2]
Internet-Draft Attestation-Bound Execution Finality September 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. From Computational Trust to Consequential Authority . . . 10
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Replacing RATS . . . . . . . . . . . . . . . . . . . . . 12
4.2. Declaring Attestation Insufficient . . . . . . . . . . . 12
4.3. Replacing OAuth or Workload Identity . . . . . . . . . . 12
4.4. Mandating Hardware . . . . . . . . . . . . . . . . . . . 12
5. Evidence Basis and Assumptions . . . . . . . . . . . . . . . 13
5.1. Reference Implementation Basis . . . . . . . . . . . . . 13
5.2. Vendor Documentation Basis . . . . . . . . . . . . . . . 13
5.3. Performance Basis . . . . . . . . . . . . . . . . . . . . 13
5.4. DPU and SmartNIC Assumption . . . . . . . . . . . . . . . 14
5.5. Review Invited . . . . . . . . . . . . . . . . . . . . . 14
6. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Candidate Act . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Non-Effective State . . . . . . . . . . . . . . . . . . . 14
6.3. Execution-Finality Validator . . . . . . . . . . . . . . 15
6.4. Protected Validation Evidence . . . . . . . . . . . . . . 16
6.5. Execution Handle . . . . . . . . . . . . . . . . . . . . 16
6.6. Finality Sink . . . . . . . . . . . . . . . . . . . . . . 17
7. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Binding Attestation to a Candidate Act . . . . . . . . . . . 19
9. Why Attestation Alone Is Not the Binding . . . . . . . . . . 20
10. Relationship to the RATS Architecture . . . . . . . . . . . . 22
11. Composite CPU and Confidential-Accelerator Environments . . . 23
12. Documentation-Based Mapping to NVIDIA GPU Attestation Results
(Not Implemented, Not Tested) . . . . . . . . . . . . . . 24
13. AI Accelerator Example . . . . . . . . . . . . . . . . . . . 26
14. Hyperscale Deployment . . . . . . . . . . . . . . . . . . . . 27
15. DPU and SmartNIC Deployment . . . . . . . . . . . . . . . . . 29
15.1. Visibility of the Candidate Act at a DPU or SmartNIC . . 30
16. Network Fabric Considerations . . . . . . . . . . . . . . . . 30
17. Relationship to Workload Identity . . . . . . . . . . . . . . 31
18. Separation of Identity, Trust, Authority, and Finality . . . 32
18.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 32
18.2. Trust . . . . . . . . . . . . . . . . . . . . . . . . . 32
18.3. Authority . . . . . . . . . . . . . . . . . . . . . . . 32
18.4. Finality . . . . . . . . . . . . . . . . . . . . . . . . 32
19. Candidate Act Canonicalization . . . . . . . . . . . . . . . 33
Das Expires 15 March 2027 [Page 3]
Internet-Draft Attestation-Bound Execution Finality September 2026
20. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 33
21. Replay Resistance . . . . . . . . . . . . . . . . . . . . . . 34
22. Non-Bearer Properties . . . . . . . . . . . . . . . . . . . . 34
23. Finality Sink Placement . . . . . . . . . . . . . . . . . . . 35
24. Finality Sink Is Not Necessarily a New Appliance . . . . . . 36
25. Hot-Path and Cold-Path Processing . . . . . . . . . . . . . . 36
26. Legacy Deployment . . . . . . . . . . . . . . . . . . . . . . 38
27. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 39
27.1. Validation Failure . . . . . . . . . . . . . . . . . . . 39
27.2. Missing Attestation Context . . . . . . . . . . . . . . 39
27.3. Expired Validation Evidence . . . . . . . . . . . . . . 39
27.4. Parameter Mutation . . . . . . . . . . . . . . . . . . . 39
27.5. Finality Sink Unavailable . . . . . . . . . . . . . . . 39
28. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 40
29. Security Considerations . . . . . . . . . . . . . . . . . . . 40
30. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
31. Example: Confidential AI Inference in a Hyperscaler . . . . . 42
32. Example: DPU-Mediated AI Egress . . . . . . . . . . . . . . . 43
33. Example: Multi-Workload Agent Chain . . . . . . . . . . . . . 44
34. Interoperability Requirements . . . . . . . . . . . . . . . . 45
35. Potential Protocol Flow . . . . . . . . . . . . . . . . . . . 46
36. Minimal Vendor-Neutral Proof-of-Concept Profile . . . . . . . 47
36.1. Protected Operation . . . . . . . . . . . . . . . . . . 47
36.2. Canonical CandidateAct . . . . . . . . . . . . . . . . . 47
36.3. EAT and Attestation-Result Input . . . . . . . . . . . . 48
36.4. Signed Execution Handle . . . . . . . . . . . . . . . . 49
36.5. Finality-Sink Processing . . . . . . . . . . . . . . . . 49
36.6. Required Test Vectors . . . . . . . . . . . . . . . . . 50
36.7. Latency Measurement and Publication . . . . . . . . . . 51
36.8. Implementation Status . . . . . . . . . . . . . . . . . 52
Implemented Components . . . . . . . . . . . . . . . . . . . 52
Reference Security Flow . . . . . . . . . . . . . . . . . . . 53
Test Results . . . . . . . . . . . . . . . . . . . . . . . . 54
Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . 54
Production Integration Boundaries . . . . . . . . . . . . . . 54
37. Why This Matters for AI Infrastructure . . . . . . . . . . . 55
38. Operational Considerations . . . . . . . . . . . . . . . . . 55
39. Discussion of Latency . . . . . . . . . . . . . . . . . . . . 56
40. Relevance to IETF Working Groups . . . . . . . . . . . . . . 57
40.1. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 57
40.2. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 57
40.3. OAUTH . . . . . . . . . . . . . . . . . . . . . . . . . 57
40.4. GNAP . . . . . . . . . . . . . . . . . . . . . . . . . . 58
40.5. HTTP (HTTPBIS) . . . . . . . . . . . . . . . . . . . . . 58
40.6. SEAT . . . . . . . . . . . . . . . . . . . . . . . . . . 58
40.7. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . 58
40.8. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 58
40.9. SECDISPATCH . . . . . . . . . . . . . . . . . . . . . . 59
Das Expires 15 March 2027 [Page 4]
Internet-Draft Attestation-Bound Execution Finality September 2026
41. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 59
42. Related Work by the Same Author . . . . . . . . . . . . . . . 60
43. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
44. Normative References . . . . . . . . . . . . . . . . . . . . 61
45. Informative References . . . . . . . . . . . . . . . . . . . 62
Appendix A. Architectural Summary . . . . . . . . . . . . . . . 65
Appendix B. Concise Statement for Discussion . . . . . . . . . . 67
Appendix C. Technical FAQ and Anticipated Engineering
Questions . . . . . . . . . . . . . . . . . . . . . . . . 67
FAQ 1. Isn't this already what a RATS Relying Party does? . . 67
FAQ 2. Is this simply AR4SI applied to individual requests? . 69
FAQ 3. How does this interact with composite CPU, CVM, GPU, and
accelerator attestation? . . . . . . . . . . . . . . . 71
FAQ 4. Does this require changes to accelerator hardware or
instruction sets? . . . . . . . . . . . . . . . . . . . 72
FAQ 5. Isn't WIMSE workload identity already enough to authorize
the operation? . . . . . . . . . . . . . . . . . . . . 74
FAQ 6. Why isn't an OAuth access token or down-scoped
transaction token sufficient? . . . . . . . . . . . . . 76
FAQ 7. Isn't the Execution Handle just another bearer
token? . . . . . . . . . . . . . . . . . . . . . . . . 77
FAQ 8. Who creates the Candidate Act, and how is it
canonicalized? . . . . . . . . . . . . . . . . . . . . 79
FAQ 9. What technically makes a Candidate Act
"non-effective"? . . . . . . . . . . . . . . . . . . . 80
FAQ 10. How does the architecture prevent TOCTOU between
authorization and execution? . . . . . . . . . . . . . 82
FAQ 11. How are replay, duplication, and retry handled at
hyperscale? . . . . . . . . . . . . . . . . . . . . . . 84
FAQ 12. Would per-act verification destroy GPU or hyperscaler
performance? . . . . . . . . . . . . . . . . . . . . . 85
FAQ 13. How does this work across multi-agent and multi-workload
chains? . . . . . . . . . . . . . . . . . . . . . . . . 87
FAQ 14. How is this different from current WIMSE
authorization-evidence/Permit work? . . . . . . . . . . 89
FAQ 15. How is this different from current RATS Action Evidence
composition work? . . . . . . . . . . . . . . . . . . . 90
FAQ 16. Does every CUDA kernel invocation need an Execution
Handle? . . . . . . . . . . . . . . . . . . . . . . . . 93
FAQ 17. What stops a compromised host from bypassing the
Finality Sink? . . . . . . . . . . . . . . . . . . . . 94
FAQ 18. Could the Finality Sink or Execution-Finality Validator
run inside GPU firmware, a DPU, SmartNIC, or a confidential
VM? . . . . . . . . . . . . . . . . . . . . . . . . . . 95
FAQ 19. What if the Execution-Finality Validator itself is
compromised? . . . . . . . . . . . . . . . . . . . . . 96
FAQ 20. Why use separate EAT-signing and
Execution-Handle-signing keys? . . . . . . . . . . . . 96
Das Expires 15 March 2027 [Page 5]
Internet-Draft Attestation-Bound Execution Finality September 2026
FAQ 21. What happens with multiple Finality Sink replicas? . . 97
FAQ 22. How does this apply to streaming AI output and batched
GPU operations? . . . . . . . . . . . . . . . . . . . . 98
FAQ 23. What happens if GPU state changes after
attestation? . . . . . . . . . . . . . . . . . . . . . 98
FAQ 24. Why isn't normal API validation at the target
enough? . . . . . . . . . . . . . . . . . . . . . . . . 99
FAQ 25. Why is the reference implementation's protected effect
stored in SQLite instead of executing a real GPU, cloud, or
payment action? . . . . . . . . . . . . . . . . . . . . 99
FAQ 26. What would be required for a genuine NVIDIA or
accelerator integration? . . . . . . . . . . . . . . . 100
Review Invited on FAQs 27 to 42 . . . . . . . . . . . . . . . . 101
FAQ 27. Is this an ordinary policy decision and enforcement
point with a signed decision? . . . . . . . . . . . . . 101
FAQ 28. Which parts of the architecture depend on the
accelerator vendor? . . . . . . . . . . . . . . . . . . 102
FAQ 29. Why is attestation-gated secret release not
sufficient? . . . . . . . . . . . . . . . . . . . . . . 102
FAQ 30. Does an in-policy act generated through prompt injection
still take effect? . . . . . . . . . . . . . . . . . . 103
FAQ 31. Do direct GPU data paths bypass the Finality Sink? . . 103
FAQ 32. How does this relate to SPDM, TDISP, and confidential
device assignment? . . . . . . . . . . . . . . . . . . 104
FAQ 33. On a shared GPU, how is the producer of an act
identified? . . . . . . . . . . . . . . . . . . . . . . 104
FAQ 34. What happens when the attestation verification service
is unavailable? . . . . . . . . . . . . . . . . . . . . 104
FAQ 35. How are harmful sequences of individually authorized
acts handled? . . . . . . . . . . . . . . . . . . . . . 105
FAQ 36. How are EFV signing keys distributed and revoked? . . 105
FAQ 37. How does this apply when the target is an external API
that will not verify handles? . . . . . . . . . . . . . 106
FAQ 38. Is the EFV a new central point of failure? . . . . . . 106
FAQ 39. How would Arm CCA attestation be consumed by an
EFV? . . . . . . . . . . . . . . . . . . . . . . . . . 107
FAQ 40. Does act binding belong in the attestation provider or
in the application layer? . . . . . . . . . . . . . . . 107
FAQ 41. Does end-to-end encryption from a confidential VM make
DPU enforcement ineffective? . . . . . . . . . . . . . 108
FAQ 42. Do handle issuance and atomic nonce verification add
unacceptable tail latency at hyperscale? . . . . . . . 109
Summary: Relationship Between RATS, WIMSE, and Execution
Finality . . . . . . . . . . . . . . . . . . . . . . . 109
Appendix D. Resources and Cross-References . . . . . . . . . . . 111
Primary Reference Implementation . . . . . . . . . . . . . . . 112
Companion Internet-Drafts . . . . . . . . . . . . . . . . . . . 112
Companion Reference Implementations . . . . . . . . . . . . . . 113
Das Expires 15 March 2027 [Page 6]
Internet-Draft Attestation-Bound Execution Finality September 2026
Other Archived Publications . . . . . . . . . . . . . . . . . . 114
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 114
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.
Composite attestation further permits trust assessments to
incorporate multiple components of a heterogeneous confidential-
computing environment.
Das Expires 15 March 2027 [Page 7]
Internet-Draft Attestation-Bound Execution Finality September 2026
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)
Figure 5
or:
Das Expires 15 March 2027 [Page 8]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
2. Motivation
Das Expires 15 March 2027 [Page 9]
Internet-Draft Attestation-Bound Execution Finality September 2026
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;
* operating across trust domains; or
Das Expires 15 March 2027 [Page 10]
Internet-Draft Attestation-Bound Execution Finality September 2026
* 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.
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.
Das Expires 15 March 2027 [Page 11]
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 15 March 2027 [Page 12]
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. Evidence Basis and Assumptions
This section states the evidence basis for statements in this
document and the assumptions under which the vendor-specific,
performance, and DPU-related discussion applies. It supplements, and
does not replace, the reference implementation described in
Section 36.8.
5.1. Reference Implementation Basis
The reference implementation was executed and tested as described in
Section 36.8. Its Attester is a software component that issues EATs
signed with a locally generated Ed25519 key. It is not NRAS or any
other vendor verifier. No vendor-issued attestation evidence or
token was used, and nothing was executed on confidential-computing
GPU, DPU, or SmartNIC hardware.
5.2. Vendor Documentation Basis
All statements about NVIDIA, Arm, AMD, and Intel platforms and
attestation services are based solely on publicly available
documentation, including [NVIDIA-ATTESTATION], [ARM-CCA-TOKEN], and
[TDX-CGPU-EAR]. None of these platforms or services was used,
simulated, or tested. Where earlier revisions of this document
stated that the architecture is illustrated with these attestation
stacks, this means discussion with reference to their public
documentation, not use in the implementation. Documentation-based
mappings are given in Section 12 and in FAQ 39.
5.3. Performance Basis
This document makes no latency or throughput claims. The discussion
of hot-path and cold-path processing describes design properties, not
measured results. Measurements of the portable reference
implementation are published with its repository and do not
characterize GPU, DPU, SmartNIC, confidential-accelerator, or
hyperscale deployments.
Das Expires 15 March 2027 [Page 13]
Internet-Draft Attestation-Bound Execution Finality September 2026
5.4. DPU and SmartNIC Assumption
The DPU discussion in Section 15 and Section 32 assumes that the DPU
can observe either the Candidate Act or the Execution Handle together
with the act digest. Where the request is encrypted end to end, see
Section 15.1.
5.5. Review Invited
This document reflects the author's current understanding of publicly
documented platform behavior, which may be incomplete or inaccurate
in places. Critical review, corrections, and counterexamples,
particularly from implementers of GPU, CPU, DPU, SmartNIC, and
attestation-verifier stacks, are explicitly invited on the RATS
mailing list or directly to the author, and will be used to refine
subsequent revisions.
6. Terminology
6.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.
6.2. Non-Effective State
A Non-Effective State is a state in which a Candidate Act may be:
* generated;
* parsed;
Das Expires 15 March 2027 [Page 14]
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.
6.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 15 March 2027 [Page 15]
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.
6.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.
6.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 15 March 2027 [Page 16]
Internet-Draft Attestation-Bound Execution Finality September 2026
* unusable for materially different operations.
6.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.
7. Architecture
The basic architecture is:
Das Expires 15 March 2027 [Page 17]
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 15 March 2027 [Page 18]
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.
8. 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 15 March 2027 [Page 19]
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.
9. Why Attestation Alone Is Not the Binding
Consider the following lifecycle:
Das Expires 15 March 2027 [Page 20]
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 15 March 2027 [Page 21]
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.
10. 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 15 March 2027 [Page 22]
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.
11. 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 15 March 2027 [Page 23]
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.
12. Documentation-Based Mapping to NVIDIA GPU Attestation Results (Not
Implemented, Not Tested)
Status: this section is a paper analysis based only on publicly
available NVIDIA attestation documentation [NVIDIA-ATTESTATION]. The
author has not used NVIDIA confidential-computing hardware, has not
obtained or verified any NRAS-issued token, has not simulated NRAS,
and has not tested any part of this mapping. Claim names are taken
from public documentation at the time of writing and may differ
between claim versions.
Role mapping: in RFC 9334 terms, a confidential-computing GPU is the
Attester, NRAS (or a local verifier) is the Verifier, the signed
token NRAS returns is the Attestation Result, and the Execution-
Finality Validator (EFV) is a Relying Party that consumes that result
as one input to an act-specific decision.
Published token structure: the documentation describes an overall
JSON Web Token with detached per-device claim sets. The overall
token carries an issuer, an overall result (x-nvidia-overall-att-
result), a nonce (eat_nonce), issue and expiry times, a token
identifier, and a submods claim holding digests of the per-device
claim sets. Per-device claims describe measurement matching
(measres), secure-boot and debug status, hardware model, and driver
and VBIOS versions.
Das Expires 15 March 2027 [Page 24]
Internet-Draft Attestation-Bound Execution Finality September 2026
How an EFV could consume it on the cold path, before issuing any
Execution Handle:
* verify the overall token signature against the issuer's published
keys;
* require the overall result to be true;
* require eat_nonce to equal a nonce the EFV itself issued;
* verify each per-device claim set against its digest in submods;
* apply local policy to per-device claims, for example measurement
success and disabled debug status; and
* treat the token expiry as an upper bound for caching the result.
Handle reference: the Execution Handle would carry a digest or
identifier of the accepted Attestation Result, not the token itself.
The Attestation Result says the GPU environment was appraised as
acceptable; the Execution Handle says one specific Candidate Act was
authorized. Presenting the Attestation Result alone to a Finality
Sink would not satisfy it.
What it does not establish: based on the published claims, the GPU
Attestation Result describes GPU identity, firmware, driver, and
configuration. It does not identify which process, agent, or model
instance produced a Candidate Act, nor the content of any operation.
Binding an act to a workload would additionally require CPU-TEE
evidence (for example [TDX-CGPU-EAR]) and a workload identity
credential, as described in Section 11 and Section 17.
Possible high-assurance variant (unvalidated): because the documented
flow uses a requester-supplied nonce, an EFV could in principle, for
rare high-consequence operation classes only, request fresh
attestation with a nonce derived from the Candidate Act digest and an
EFV-issued random value. This has not been evaluated. Open
questions include accepted nonce format and length, latency, verifier
rate limits and availability, and operational acceptability.
Ordinary operations would use cached results as in Section 25.
Not done: execution on confidential-computing GPUs; retrieval or
verification of an NRAS token; use of the NVIDIA Attestation SDK or
CLI; latency measurement; BlueField or DOCA integration; review by
NVIDIA. This mapping is a starting point for implementers and
discussion only.
Das Expires 15 March 2027 [Page 25]
Internet-Draft Attestation-Bound Execution Finality September 2026
13. 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.
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:
Das Expires 15 March 2027 [Page 26]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
14. Hyperscale Deployment
A hyperscale deployment can place the architecture across existing
infrastructure.
Example:
Das Expires 15 March 2027 [Page 27]
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 15 March 2027 [Page 28]
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.
15. 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 15 March 2027 [Page 29]
Internet-Draft Attestation-Bound Execution Finality September 2026
However, this architecture does not require that a DPU or SmartNIC
perform this function.
15.1. Visibility of the Candidate Act at a DPU or SmartNIC
A DPU or SmartNIC can act as a Finality Sink only if it can verify
the binding between the Execution Handle and the Candidate Act. If
the workload encrypts its outbound request end to end, for example
with TLS originating inside a confidential VM, the DPU sees only
ciphertext and cannot reconstruct the Candidate Act. Confidential-
computing threat models also commonly place operator-managed
infrastructure, including DPUs, outside the tenant's trusted
computing base.
Deployments can resolve this in at least three ways:
1. Trusted terminating proxy: the DPU terminates the workload's TLS,
reconstructs the Candidate Act, verifies the handle, and re-
originates the request. The DPU's own environment must then be
attested and accepted by the tenant.
2. Split verification: the handle and act digest travel in an outer
layer visible to the DPU while the request body stays encrypted.
The DPU enforces handle validity and single use; the destination
verifies that the request matches the act digest.
3. Destination-side sink: the Finality Sink sits at or directly in
front of the target system, and the DPU provides only isolation
and routing.
Where none of these conditions can be met, the DPU is not an
appropriate Finality Sink location for that deployment.
16. Network Fabric Considerations
Execution finality is independent of network bandwidth and transport
technology.
A Candidate Act can traverse:
* PCIe;
* accelerator interconnects;
* Ethernet;
* InfiniBand;
Das Expires 15 March 2027 [Page 30]
Internet-Draft Attestation-Bound Execution Finality September 2026
* 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.
17. 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.
The relationship can therefore be expressed as:
Workload identity
|
+-------------------+
|
v
Candidate Act
|
v
act authorization
|
v
external effect
Figure 30
Das Expires 15 March 2027 [Page 31]
Internet-Draft Attestation-Bound Execution Finality September 2026
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].
18. 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.
18.1. Identity
Who or what is this workload?
Figure 31
18.2. Trust
What properties can be established about the environment?
Figure 32
Remote attestation primarily contributes here.
18.3. Authority
Is this concrete operation permitted under the relevant
identity, trust state, scope, policy, and context?
Figure 33
18.4. Finality
Has the required authorization been established at the
boundary where the operation would acquire consequence?
Figure 34
Das Expires 15 March 2027 [Page 32]
Internet-Draft Attestation-Bound Execution Finality September 2026
19. 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
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.
20. Freshness
Validation evidence should be bounded in time or transaction context
when stale authorization would create security risk.
Das Expires 15 March 2027 [Page 33]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
21. 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:
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.
22. Non-Bearer Properties
A conventional bearer credential can confer authority primarily
through possession.
For high-consequence execution, a deployment may require stronger
binding.
Das Expires 15 March 2027 [Page 34]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
23. 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.
Das Expires 15 March 2027 [Page 35]
Internet-Draft Attestation-Bound Execution Finality September 2026
For example:
AI agent
|
Candidate Acts
_________|_________
| | |
v v v
payment storage network
sink sink sink
Figure 40
24. 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;
* 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.
25. 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;
Das Expires 15 March 2027 [Page 36]
Internet-Draft Attestation-Bound Execution Finality September 2026
* 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;
* proof verification; and
* finality enforcement.
For example:
Das Expires 15 March 2027 [Page 37]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
26. 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 15 March 2027 [Page 38]
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.
27. Failure Modes
27.1. Validation Failure
If required validation fails, the Candidate Act remains non-
effective.
27.2. Missing Attestation Context
Where policy requires an acceptable Attestation Result and no
acceptable result exists, validation fails.
27.3. Expired Validation Evidence
Expired evidence is rejected where freshness is required.
27.4. Parameter Mutation
If security-relevant Candidate Act parameters change after
validation, the original validation binding no longer authorizes the
modified act.
27.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 15 March 2027 [Page 39]
Internet-Draft Attestation-Bound Execution Finality September 2026
28. 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.
29. 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 15 March 2027 [Page 40]
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.
30. 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 15 March 2027 [Page 41]
Internet-Draft Attestation-Bound Execution Finality September 2026
31. 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 15 March 2027 [Page 42]
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.
32. 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 15 March 2027 [Page 43]
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.
33. 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 15 March 2027 [Page 44]
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
34. 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 15 March 2027 [Page 45]
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.
35. 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 15 March 2027 [Page 46]
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.
36. 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.
36.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.
36.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 15 March 2027 [Page 47]
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.
36.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 15 March 2027 [Page 48]
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.
36.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.
36.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 15 March 2027 [Page 49]
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.
36.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 15 March 2027 [Page 50]
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
36.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 15 March 2027 [Page 51]
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.
36.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 15 March 2027 [Page 52]
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 15 March 2027 [Page 53]
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 36.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.
Benchmarks
Benchmark scripts and their measured output for the portable
implementation are included in the repository [EF-GPU-GITHUB]. This
document does not reproduce or rely on those figures and makes no
latency or throughput claims (Section 5.3).
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
* independent security review, including threat modeling, dependency
review, fuzzing and penetration testing.
Das Expires 15 March 2027 [Page 54]
Internet-Draft Attestation-Bound Execution Finality September 2026
The reference implementation proves executable feasibility for the
narrow profile above and supplies reproducible negative tests and
byte-level vectors. It does not prove IETF adoption, universal
applicability, hyperscale performance, or suitability for real
financial processing.
37. 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.
38. 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:
Das Expires 15 March 2027 [Page 55]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
39. 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.
These are design properties, not measured results; no latency figures
are claimed for any deployment (Section 5.3).
Das Expires 15 March 2027 [Page 56]
Internet-Draft Attestation-Bound Execution Finality September 2026
40. Relevance to IETF Working Groups
This section identifies IETF working groups whose existing or ongoing
work overlaps with this architecture, what this document takes from
each, and which questions may be relevant to each. It does not claim
that any working group has reviewed, discussed, or adopted this
document. The assessments reflect the author's reading of each
group's public work and may be inaccurate; corrections are invited.
40.1. RATS
RATS is the primary venue for this document. The architecture
consumes RATS outputs without changing RATS roles: Evidence and
Attestation Results [RFC9334]; EAT [RFC9711] and its profiles, such
as the Arm CCA token [ARM-CCA-TOKEN]; composite attestation,
including the composite EAT profile work in [COMPOSITE-EAT]; device-
assignment attestation [EAT-DA]; and Attestation Results for Secure
Interactions (FAQ 2). Questions that may be relevant to RATS are how
an Attestation Result is referenced by digest from an act-bound
artifact, how composite and multi-verifier results are represented in
such a reference, and whether appraisal-policy guidance can describe
the transition from environment appraisal to operation-specific
authorization. Whether act-level authorization itself falls within
the RATS charter is an open question; it may instead belong in WIMSE
or OAUTH (Section 41).
40.2. WIMSE
WIMSE supplies workload identity and workload credentials that bind a
Candidate Act to the workload that produced it (Section 17). WIMSE
authorization-evidence work, compared in FAQ 14, addresses pre-
execution authorization records bound to request content and is the
closest existing work to the Execution Handle. Questions that may be
relevant to WIMSE are whether an Execution Handle can be a profile of
that work, how act binding is carried across multi-workload chains
(FAQ 13), and how attestation references attach to workload
credentials.
40.3. OAUTH
Several OAuth mechanisms can supply parts of the architecture.
Transaction Tokens [OAUTH-TXN-TOKENS] propagate user identity,
workload identity, and authorization context through a call chain
within a trusted domain (FAQ 6). Rich Authorization Requests
[RFC9396] can express the parameters of a Candidate Act as
authorization details. DPoP [RFC9449] provides proof of possession,
one route to the non-bearer property (Section 22). Token Exchange
[RFC8693] can derive a narrowly scoped token for a single act. The
Das Expires 15 March 2027 [Page 57]
Internet-Draft Attestation-Bound Execution Finality September 2026
question that may be relevant to OAUTH is whether a transaction-token
or token-exchange profile carrying an act digest and an attestation
reference can provide the Execution Handle, including single-use
enforcement at the resource server.
40.4. GNAP
GNAP [RFC9635] supports fine-grained access requests and access
tokens bound to a client key by default, both of which align with
act-bound, non-bearer authorization. The question that may be
relevant to GNAP is whether an access request can describe a single
Candidate Act and whether the resulting token can be restricted to
that act and to one use.
40.5. HTTP (HTTPBIS)
For HTTP-carried acts, HTTP Message Signatures [RFC9421] can carry an
EFV signature over the request components that make up the Candidate
Act, and Digest Fields [RFC9530] can carry the body digest used in
canonicalization (Section 19). These are existing mechanisms; no new
HTTP work is proposed.
40.6. SEAT
The Secure Evidence and Attestation Transport (SEAT) working group is
chartered to define a (D)TLS extension for peer or mutual attestation
bound to the (D)TLS connection, with per-connection freshness of
Evidence and Attestation Results. Attested TLS is relevant to the
trusted terminating proxy option in Section 15.1, where a tenant
needs assurance about a DPU before exposing plaintext Candidate Acts
to it, and to binding Execution Handles to an attested channel.
40.7. SCITT
SCITT defines transparency services for signed statements. An EFV
decision, or the digest of an issued Execution Handle, could be
registered as a signed statement to give auditors a tamper-evident
record of which acts were authorized. This is optional and not
required by the architecture.
40.8. COSE
The reference profile uses COSE_Sign1 [RFC9052] and deterministic
CBOR [RFC8949]. A future Execution Handle format would likely be a
COSE or CWT profile, making COSE conventions for algorithms and key
identification directly relevant.
Das Expires 15 March 2027 [Page 58]
Internet-Draft Attestation-Bound Execution Finality September 2026
40.9. SECDISPATCH
If the act-level authorization layer is judged not to fit an existing
working group, SECDISPATCH is the venue for deciding where, or
whether, such work belongs.
41. 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?
11. How should cumulative limits across sequences of individually
authorized acts be enforced across replicated EFVs and Finality
Sinks?
Das Expires 15 March 2027 [Page 59]
Internet-Draft Attestation-Bound Execution Finality September 2026
12. Where end-to-end encryption prevents a DPU or SmartNIC from
observing the Candidate Act, which split-verification encoding
is appropriate?
42. 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 45,
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
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-
Das Expires 15 March 2027 [Page 60]
Internet-Draft Attestation-Bound Execution Finality September 2026
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
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 36.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).
43. 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.
44. Normative References
Das Expires 15 March 2027 [Page 61]
Internet-Draft Attestation-Bound Execution Finality September 2026
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, January 2023,
<https://www.rfc-editor.org/info/rfc9334>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "Entity Attestation Token (EAT)", RFC 9711, April
2025, <https://www.rfc-editor.org/info/rfc9711>.
45. 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",
<https://docs.nvidia.com/attestation/index.html>. Vendor
documentation, cited informatively in Section 12 and
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)",
<https://github.com/sangmdas/Execution-Finality-for-GPU-
Das Expires 15 March 2027 [Page 62]
Internet-Draft Attestation-Bound Execution Finality September 2026
AI-Accelerators-and-Confidential-Workloads/>. Source
repository for the reference implementation described in
Section 36.8.
[EF-GPU-ZENODO]
Das, S., "From Attested GPU Computation to Authorized
Action: Execution Finality for AI Accelerators and
Confidential Workloads", 2026,
<https://zenodo.org/records/22308384>. Archived, citable
snapshot of the reference implementation and accompanying
material described in Section 36.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,
<https://datatracker.ietf.org/doc/draft-das-protocols-
enterprise-ai/>. 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, <https://datatracker.ietf.org/doc/draft-das-
rats-frontier-model-extraction/>. 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,
<https://datatracker.ietf.org/doc/draft-das-enterprise-ai-
output-finality/>. Work in progress.
[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,
Das Expires 15 March 2027 [Page 63]
Internet-Draft Attestation-Bound Execution Finality September 2026
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-ai-interoperability/>. 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, <https://datatracker.ietf.org/doc/draft-das-
agentic-tool-binding/>. 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,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-protocol-layer/>. 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.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[EAT-DA] Poirier, M., Birkholz, H., and T. Fossati, "An EAT Profile
for Trustworthy Device Assignment", Work in Progress,
Internet-Draft, draft-poirier-rats-eat-da-10, 2026,
<https://datatracker.ietf.org/doc/draft-poirier-rats-eat-
da/>.
[ARM-CCA-TOKEN]
Frost, S., Fossati, T., and G. Mandyam, "Arm's
Confidential Compute Architecture Reference Attestation
Token", Work in Progress, Internet-Draft, draft-ffm-rats-
cca-token-03, March 2026,
<https://datatracker.ietf.org/doc/draft-ffm-rats-cca-
token/>.
[COMPOSITE-EAT]
Sun, X., Krishnamurthy, R., and R. Golizadeh Mojarad, "An
EAT Profile for Composite Platform Attestation", Work in
Das Expires 15 March 2027 [Page 64]
Internet-Draft Attestation-Bound Execution Finality September 2026
Progress, Internet-Draft, draft-sun-rats-composite-eat-00,
September 2026, <https://datatracker.ietf.org/doc/draft-
sun-rats-composite-eat/>.
[OAUTH-TXN-TOKENS]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens, 2026,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-
transaction-tokens/>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>.
[RFC9635] Richer, J. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/info/rfc9635>.
Appendix A. Architectural Summary
The complete transition can be summarized as:
TRUST PLANE
Evidence / Attestation
|
v
Verifier
|
v
Attestation Result
Das Expires 15 March 2027 [Page 65]
Internet-Draft Attestation-Bound Execution Finality September 2026
|
|
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
|
v
FINALITY PLANE
Finality Sink
|
v
EXTERNAL EFFECT
Figure 63
The principal distinction is:
Das Expires 15 March 2027 [Page 66]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
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.
Das Expires 15 March 2027 [Page 67]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
Attestation Result
+
Candidate Act
+
workload identity
+
policy/context
|
v
act-specific authorization
|
v
protected act binding
|
v
Finality Sink
|
v
External Effect
Figure 66
Das Expires 15 March 2027 [Page 68]
Internet-Draft Attestation-Bound Execution Finality September 2026
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*
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:
Das Expires 15 March 2027 [Page 69]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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.
Das Expires 15 March 2027 [Page 70]
Internet-Draft Attestation-Bound Execution Finality September 2026
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
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.
Das Expires 15 March 2027 [Page 71]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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*
Das Expires 15 March 2027 [Page 72]
Internet-Draft Attestation-Bound Execution Finality September 2026
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
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:
Das Expires 15 March 2027 [Page 73]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
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.
Das Expires 15 March 2027 [Page 74]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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.
Das Expires 15 March 2027 [Page 75]
Internet-Draft Attestation-Bound Execution Finality September 2026
*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:
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:
Das Expires 15 March 2027 [Page 76]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
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:
Das Expires 15 March 2027 [Page 77]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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.
Das Expires 15 March 2027 [Page 78]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
method
authority
path
selected headers
body
target resource
Figure 88
For an RPC:
service
method
arguments
target
Figure 89
For a cloud-control operation:
Das Expires 15 March 2027 [Page 79]
Internet-Draft Attestation-Bound Execution Finality September 2026
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
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*
Das Expires 15 March 2027 [Page 80]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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.
Das Expires 15 March 2027 [Page 81]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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
Das Expires 15 March 2027 [Page 82]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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.
Das Expires 15 March 2027 [Page 83]
Internet-Draft Attestation-Bound Execution Finality September 2026
*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
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.
Das Expires 15 March 2027 [Page 84]
Internet-Draft Attestation-Bound Execution Finality September 2026
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*
The architecture is designed to avoid that: expensive appraisal stays
on the cold path and per-act work is limited to local verification.
Per-act overhead on accelerator or hyperscale infrastructure has not
been measured (Section 5.3).
The architecture should explicitly separate the cold path from the
hot path.
Das Expires 15 March 2027 [Page 85]
Internet-Draft Attestation-Bound Execution Finality September 2026
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:
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
Das Expires 15 March 2027 [Page 86]
Internet-Draft Attestation-Bound Execution Finality September 2026
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
Several identities can contribute to the decision:
initiating principal
delegated subject
Agent A workload identity
Planner B identity
Broker C identity
Execution Service identity
Das Expires 15 March 2027 [Page 87]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
Execution finality provides a possible terminal enforcement semantic:
Das Expires 15 March 2027 [Page 88]
Internet-Draft Attestation-Bound Execution Finality September 2026
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.
Execution finality requires identifying an effectuation boundary and
making successful verification load-bearing for the consequence:
Das Expires 15 March 2027 [Page 89]
Internet-Draft Attestation-Bound Execution Finality September 2026
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?
*Answer*
This is the other comparison the document should confront directly.
Das Expires 15 March 2027 [Page 90]
Internet-Draft Attestation-Bound Execution Finality September 2026
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 15 March 2027 [Page 91]
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 15 March 2027 [Page 92]
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 15 March 2027 [Page 93]
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 15 March 2027 [Page 94]
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 36.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 15 March 2027 [Page 95]
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 15 March 2027 [Page 96]
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 15 March 2027 [Page 97]
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 15 March 2027 [Page 98]
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 15 March 2027 [Page 99]
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 36.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 15 March 2027 [Page 100]
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.
Review Invited on FAQs 27 to 42
FAQs 27 to 42 were added in this revision to address questions that
accelerator, DPU, SmartNIC, and confidential-computing platform
engineers are likely to raise. They reflect the author's current
understanding of publicly documented platform behavior, which may be
incomplete or inaccurate in places. Critical review is explicitly
invited. Corrections, counterexamples, and identification of
mistaken assumptions, particularly from implementers of GPU, DPU,
SmartNIC, and attestation-verifier stacks, are welcome on the RATS
mailing list or directly to the author, and will be used to refine
subsequent revisions.
FAQ 27. Is this an ordinary policy decision and enforcement point with
a signed decision?
*Question*
Policy decision and enforcement points, capability tokens, OAuth
transaction tokens, and HTTP Message Signatures already exist. What
does this architecture add?
*Answer*
Each building block exists, and the architecture is intended to reuse
them rather than replace them. The contribution is a required
combination of properties for protected operation classes: the
authorization artifact is bound to a digest of the exact canonical
Candidate Act; it references an accepted Attestation Result rather
than carrying or replacing it; it is audience-bound, single-use, and
non-bearer; it is signed with a key distinct from any Attester key;
and no path to the protected effect exists that does not traverse a
Finality Sink verifying it. A conventional policy decision can
satisfy several of these properties without satisfying the non-bypass
requirement, which is the property that determines whether a
consequence can occur without authorization. An act-bound artifact
can be expressed as a profile of existing mechanisms; for HTTP-
carried acts, HTTP Message Signatures [RFC9421] is a candidate
carrier for an EFV signature over the request components that
constitute the Candidate Act.
Das Expires 15 March 2027 [Page 101]
Internet-Draft Attestation-Bound Execution Finality September 2026
FAQ 28. Which parts of the architecture depend on the accelerator
vendor?
*Question*
Does the architecture require changes to silicon, firmware, drivers,
or accelerator programming models, and what does it depend on from
accelerator vendors?
*Answer*
It requires no changes to silicon, firmware, drivers, programming
models, or kernel execution (see also FAQ 4 and FAQ 16). It depends
on accelerator platforms in three places only: Attestation Results
that an EFV can verify and reference by digest; claim sets stable
enough to be named in EFV policy across claim-version changes; and,
where a deployment chooses, DPUs or SmartNICs capable of hosting a
Finality Sink. The enforcement boundary is the effectuation point of
the consequential operation, which usually lies outside the
accelerator.
FAQ 29. Why is attestation-gated secret release not sufficient?
*Question*
Key broker services, such as the Trustee component of Confidential
Containers, release secrets only to attested workloads. Why is that
not sufficient?
*Answer*
Attestation-gated release evaluates the environment at the moment a
secret is released. Once a target-system credential is released into
the workload, every subsequent operation using that credential is
authorized by possession, including operations generated through
prompt injection or model error; inside the workload, the credential
behaves as a bearer credential. Execution finality moves the
decision from credential release to each protected act. The
strongest deployment pattern does not release the target credential
to the workload at all: the Finality Sink holds it and uses it only
after verifying an act-bound Execution Handle. Attestation-gated
release remains appropriate for model weights, data keys, and the
EFV's own signing key.
Das Expires 15 March 2027 [Page 102]
Internet-Draft Attestation-Bound Execution Finality September 2026
FAQ 30. Does an in-policy act generated through prompt injection still
take effect?
*Question*
If a prompt-injected or malfunctioning agent generates an act that
fits the granted scope and policy, does the architecture stop it?
*Answer*
No. Execution finality does not detect malicious intent or model
error. It guarantees that acts outside the granted scope cannot take
effect, that an approved act cannot be altered between approval and
effect, and that no path reaches the protected effect except through
the Finality Sink. Harm within the granted scope is reduced only by
narrow operation scopes, by operation classes that require human or
out-of-band approval before a handle is issued, and by cumulative
limits (FAQ 35). The architecture changes "the workload can do
anything its credentials allow" into "the workload can do only what
was specifically authorized", which bounds in-scope misuse but does
not eliminate it.
FAQ 31. Do direct GPU data paths bypass the Finality Sink?
*Question*
GPUDirect RDMA, GPUDirect Storage, and NVLink move data between GPUs,
NICs, and storage without traversing the CPU. Do these paths bypass
the Finality Sink?
*Answer*
They can, and the non-bypass requirement applies to them. Data
movement is not in itself a protected consequence, but a write to
protected storage or a transfer to a destination outside the trust
domain can be. Where such a path can reach a protected effect, the
Finality Sink is placed where the effect is committed, for example at
the storage target or at a DPU on the storage or network path, or the
path is disabled for that workload. GPU-to-GPU transfers within a
single trust domain are treated as internal computation; transfers
between workloads or tenants are treated as a multi-workload chain
(FAQ 13). A deployment in which a direct data path reaches a
protected effect without traversing a Finality Sink does not satisfy
this architecture for that effect.
Das Expires 15 March 2027 [Page 103]
Internet-Draft Attestation-Bound Execution Finality September 2026
FAQ 32. How does this relate to SPDM, TDISP, and confidential device
assignment?
*Question*
SPDM, TDISP, and confidential device assignment already establish
whether a device can be trusted by a confidential VM. How does
execution finality relate to them?
*Answer*
They answer different questions. SPDM, TDISP, and device-assignment
attestation (for example the EAT profile in [EAT-DA]) determine
whether a device may be admitted into a confidential VM's trust
boundary. Execution finality determines whether a specific operation
may take effect. The two compose: where a platform can assign a DPU
or SmartNIC function into the tenant's trust boundary through device
assignment, that function becomes a candidate Finality Sink location
that the tenant can trust with plaintext Candidate Acts. This
composition has not been evaluated on any specific product.
FAQ 33. On a shared GPU, how is the producer of an act identified?
*Question*
GPU Attestation Results describe a device. When a GPU is shared or
partitioned, how does the EFV determine which tenant or workload
produced a Candidate Act?
*Answer*
Not from the GPU Attestation Result alone. GPU attestation describes
device identity, firmware, and configuration, not the process or
agent that produced an operation. Binding a Candidate Act to a
tenant or workload requires CPU-TEE evidence for the confidential VM
or container that submitted it, combined with a workload identity
credential (Section 11, Section 17). Where a platform provides per-
partition attestation, that is an additional input; this document has
not evaluated whether any specific platform provides it.
FAQ 34. What happens when the attestation verification service is
unavailable?
*Question*
If a remote attestation service such as NRAS is unreachable, do
protected operations stop?
Das Expires 15 March 2027 [Page 104]
Internet-Draft Attestation-Bound Execution Finality September 2026
*Answer*
Only protected operation classes are affected, and only after cached
Attestation Results expire; ordinary traffic is unaffected. Vendor
documentation describes a local verification option for air-gapped
environments [NVIDIA-ATTESTATION], which removes the runtime
dependency at the cost of possibly stale revocation data. Failing
closed for protected classes is intentional: an operation classified
as consequential does not take effect without acceptable trust
context. Operators control which classes are protected and how long
results may be cached (Section 20).
FAQ 35. How are harmful sequences of individually authorized acts
handled?
*Question*
An agent can split a harmful outcome into many small acts, each
individually within policy. Does per-act authorization stop this?
*Answer*
Not by itself. Binding each act to its own authorization does not
detect harmful aggregates. The EFV therefore maintains state, such
as per-workload budgets, counters, and rate limits, evaluated before
handle issuance and decremented at the Finality Sink in the same
atomic transaction that consumes the handle's nonce, so that
concurrent acts cannot jointly exceed a limit. With a single EFV and
sink this is a local transaction; across replicated EFVs and sinks it
requires shared transactional state (FAQ 21) and remains an open
question for this architecture.
FAQ 36. How are EFV signing keys distributed and revoked?
*Question*
How do Finality Sinks obtain EFV verification keys, and what happens
if an EFV signing key is compromised?
*Answer*
Finality Sinks hold EFV public keys as provisioned trust anchors
identified by key identifier. Execution Handles are short-lived, so
expiry is the primary revocation mechanism. On compromise, the
operator removes the affected key identifier from sink trust stores,
after which handles issued under that key are rejected; no handle
outlives its validity interval in any case. The EFV signing key is
held in an HSM or equivalent, or released to the EFV only after the
Das Expires 15 March 2027 [Page 105]
Internet-Draft Attestation-Bound Execution Finality September 2026
EFV's own environment has been attested. Because EFV and Attester
keys are separate (FAQ 20), compromise of one does not confer the
capabilities of the other.
FAQ 37. How does this apply when the target is an external API that
will not verify handles?
*Question*
Most consequential operations target third-party services that will
not implement Execution Handle verification. How does the
architecture apply?
*Answer*
The Finality Sink is placed at the deploying organization's own
egress point. The sink verifies the Execution Handle, removes it,
and forwards the request using a target credential that the sink
holds and the workload does not. The guarantee then covers the
deploying side of the boundary: no request reaches the external
service without an act-bound authorization. The external service
receives no proof of that authorization, and actions it takes after
receiving the request are outside the scope of this architecture.
FAQ 38. Is the EFV a new central point of failure?
*Question*
A validator that must approve every protected act appears to be a
throughput bottleneck and a denial-of-service target. How is that
addressed?
*Answer*
Hot-path verification is local to the Finality Sink: it checks
signature, audience, validity interval, act digest, and nonce without
contacting the EFV (Section 25). The EFV is involved only when a
handle is issued. EFV instances can be replicated because handles
are self-verifying, but replay state and cumulative limits then
require shared transactional storage (FAQ 21, FAQ 35). An attacker
able to overwhelm the EFV can prevent protected acts, which is a
denial of service but not an unauthorized consequence; ordinary
traffic is unaffected. Throughput at hyperscale has not been
measured.
Das Expires 15 March 2027 [Page 106]
Internet-Draft Attestation-Bound Execution Finality September 2026
FAQ 39. How would Arm CCA attestation be consumed by an EFV?
*Question*
Arm Confidential Compute Architecture (CCA) Realms produce their own
attestation tokens. How would they feed this architecture?
*Answer*
This answer is based only on the published CCA attestation token
specification [ARM-CCA-TOKEN]; no Arm hardware, simulation model, or
CCA token has been used or tested. According to that specification,
the CCA attestation token is a profile of EAT made up of a CCA
Platform token and a Realm state token, presented together in a
Conceptual Message Wrapper collection, and corresponds to Evidence in
RFC 9334 terms. A Verifier appraises that Evidence and produces an
Attestation Result, which the EFV consumes on the cold path in the
same way as any other Attestation Result. Because the Realm token
describes the Realm, that is, the confidential VM, it is the natural
input for identifying the confidential environment that submitted a
Candidate Act; identifying a specific process or agent inside the
Realm still requires a workload identity credential (FAQ 33). The
Execution Handle would reference the accepted Attestation Result by
digest rather than carry the token. The specification defines
challenge claims used for freshness; whether an act-derived challenge
could bind a fresh Realm attestation to one specific high-consequence
act, as considered for GPU attestation in Section 12, has not been
evaluated.
FAQ 40. Does act binding belong in the attestation provider or in the
application layer?
*Question*
Hardware attestation providers treat their role as ending at the
execution-platform boundary: proving microcode, VBIOS, reference
measurements, and driver state. Binding application payloads, API
verbs such as POST /payment, and policy decisions belongs to
application runtimes, API gateways, and service meshes. Does this
architecture ask attestation providers to take on that role?
*Answer*
No, and the architecture is consistent with that layering. Platform
attestation providers supply Attestation Results and nothing more;
they are not asked to inspect payloads, evaluate policy, or issue
Execution Handles (FAQ 28). The EFV and Finality Sink are
application-layer functions, and their natural implementations are
Das Expires 15 March 2027 [Page 107]
Internet-Draft Attestation-Bound Execution Finality September 2026
the components named in the question: API gateways, service-mesh
proxies such as the Envoy proxies used by Istio, and workload
identity systems such as SPIFFE/SPIRE and WIMSE. What this document
adds to that layer is a defined way to consume the platform's
Attestation Result as an input to an act-bound decision, by reference
rather than by re-interpretation, together with the non-bypass
requirement at the effect boundary. The division is: the platform
proves what is running; the application layer decides and enforces
what may take effect.
FAQ 41. Does end-to-end encryption from a confidential VM make DPU
enforcement ineffective?
*Question*
If a tenant in a confidential VM encrypts traffic end to end to an
external endpoint, the DPU cannot inspect the Candidate Act without
entering the tenant's trust boundary or using an attested proxy.
Does this undermine DPU-based enforcement in zero-trust multi-tenant
clouds?
*Answer*
It limits it, and the limit is structural. Under split verification
(Section 15.1), the DPU can enforce, without seeing plaintext, that
no protected-class request leaves the host without a valid,
unexpired, unused Execution Handle, and it can compare any
destination information visible to it, such as the address or an
unencrypted TLS server name, with the target recorded in the handle.
It cannot verify that the encrypted payload matches the act digest: a
compromised workload could attach a valid handle to a different
encrypted request. Act binding is then enforced only if the
destination verifies the digest. Where the destination is an
external service that does not verify handles (FAQ 37), split
verification provides authorization presence and single use but not
act binding; full enforcement then requires a tenant-trusted egress
proxy that the workload cannot bypass, which may be a DPU function
admitted into the tenant's trust boundary through device assignment
(FAQ 32). DPU enforcement is therefore strongest where the
operator's own workloads or first-party services are being protected,
or where the DPU function is admitted into the tenant's trust
boundary. In zero-trust multi-tenant deployments without such
admission, the DPU is a supplementary control and the primary
Finality Sink is placed elsewhere.
Das Expires 15 March 2027 [Page 108]
Internet-Draft Attestation-Bound Execution Finality September 2026
FAQ 42. Do handle issuance and atomic nonce verification add
unacceptable tail latency at hyperscale?
*Question*
At hyperscale, cryptographic handle issuance and atomic nonce
verification on high-throughput inference chains risk adding tail
latency, which AI infrastructure teams resist unless it is required
for regulated transactions. How does the architecture address this?
*Answer*
The architecture is not applied to inference request chains.
Finality applies only at consequence boundaries such as payments,
deletions, deployments, and control-plane changes (Section 38); token
generation, model reasoning, and read-only calls are not on the
finality path. Where it does apply, the dominant cost is not
signature verification but atomic single-use state, which becomes a
distributed coordination problem when many sink replicas can commit
the same consequence (FAQ 21). Two design choices reduce that cost.
First, binding each handle's audience to one sink instance or shard
keeps replay state local, so no cross-replica agreement is needed per
request, at the cost of less flexible request routing. Second, where
the sink is a transactional store, consuming the nonce inside the
same commit transaction as the protected effect adds one write to an
existing transaction rather than an additional round trip. No tail-
latency figures are claimed (Section 5.3), and measuring 99th-
percentile overhead on production-scale infrastructure remains open
work. The architecture is aimed first at operation classes where
regulation or consequence already justifies an additional
authorization step, such as financial transactions, healthcare
actions, and infrastructure control; it does not propose mandatory
application to all agent traffic.
Summary: Relationship Between RATS, WIMSE, and Execution Finality
The three layers can be summarized as follows:
Das Expires 15 March 2027 [Page 109]
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 15 March 2027 [Page 110]
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.
Appendix D. Resources and Cross-References
The following resources are listed for cross-reference. Companion
Internet-Drafts apply the same execution-finality architecture to
other domains; none is a prerequisite for this document. Companion
reference implementations are listed for context only and have not
been evaluated against the profile defined in this document.
Das Expires 15 March 2027 [Page 111]
Internet-Draft Attestation-Bound Execution Finality September 2026
Primary Reference Implementation
* GitHub: https://github.com/sangmdas/Execution-Finality-for-GPU-AI-
Accelerators-and-Confidential-Workloads
* Zenodo archived snapshot: https://zenodo.org/records/22308384
Companion Internet-Drafts
* draft-das-execution-finality-protocol-layer:
https://datatracker.ietf.org/doc/draft-das-execution-finality-
protocol-layer/
* draft-das-agentic-tool-binding: https://datatracker.ietf.org/doc/
draft-das-agentic-tool-binding/
* draft-das-execution-finality-ai-interoperability:
https://datatracker.ietf.org/doc/draft-das-execution-finality-ai-
interoperability/
* draft-das-rats-frontier-model-extraction:
https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-
extraction/
* draft-das-rats-openai-anthropic-extraction:
https://datatracker.ietf.org/doc/draft-das-rats-openai-anthropic-
extraction/
* draft-das-enterprise-ai-output-finality:
https://datatracker.ietf.org/doc/draft-das-enterprise-ai-output-
finality/
* draft-das-protocols-enterprise-ai:
https://datatracker.ietf.org/doc/draft-das-protocols-enterprise-
ai/
* draft-das-hardware-enforced-execution-finality:
https://datatracker.ietf.org/doc/draft-das-hardware-enforced-
execution-finality/
* draft-das-agentic-execution-finality:
https://datatracker.ietf.org/doc/draft-das-agentic-execution-
finality/
* draft-agentic-ai-tool-execution-finality:
https://datatracker.ietf.org/doc/draft-agentic-ai-tool-execution-
finality/
Das Expires 15 March 2027 [Page 112]
Internet-Draft Attestation-Bound Execution Finality September 2026
* draft-das-protocols-candidate-act-finality:
https://datatracker.ietf.org/doc/draft-das-protocols-candidate-
act-finality/
* draft-das-child-safe-rendering-finality:
https://datatracker.ietf.org/doc/draft-das-child-safe-rendering-
finality/
* draft-das-payment-execution-finality:
https://datatracker.ietf.org/doc/draft-das-payment-execution-
finality/
* draft-das-precision-bounded-egress:
https://datatracker.ietf.org/doc/draft-das-precision-bounded-
egress/
* draft-das-eu-ai-act-execution-enforcement:
https://datatracker.ietf.org/doc/draft-das-eu-ai-act-execution-
enforcement/
* draft-das-digital-sovereignty-finality:
https://datatracker.ietf.org/doc/draft-das-digital-sovereignty-
finality/
* draft-das-ai-native-6g-execution-finality:
https://datatracker.ietf.org/doc/draft-das-ai-native-6g-execution-
finality/
* draft-das-ot-actuation-finality: https://datatracker.ietf.org/doc/
draft-das-ot-actuation-finality/
Companion Reference Implementations
* https://github.com/sangmdas/Execution-Finality-for-AI-Agents-GPUs-
Confidential-Computing-and-Zero-Trust-Automation
* https://github.com/sangmdas/Hardware-Execution-Finality-for-AI-
and-Autonomous-Systems
* https://github.com/sangmdas/Execution-Finality-for-Protected-AI-
Model-State-Release-RATS-Reference-Implementation
* https://github.com/sangmdas/execution-finality-rats-ai-model-
release
* https://github.com/sangmdas/tool_use-Is-Not-invoke-Binding-
Execution-Finality-to-Agentic-Tool-Call-Interfaces-and-MCP
Das Expires 15 March 2027 [Page 113]
Internet-Draft Attestation-Bound Execution Finality September 2026
* https://github.com/sangmdas/Protected-Rendering-Finality-for-
Child-Safety-GPU-Compositor-Display-and-Media-Enforcement
* https://github.com/sangmdas/Payment-Execution-Finality-for-
Agentic-API-and-Automated-Payments-Runnable-Reference-
Implementation
* https://github.com/sangmdas/Preventing-AI-Hallucinations-and-
Unauthorized-Actions-Runnable-Reference-Implementation
* https://github.com/sangmdas/Execution-Finality-Security-for-
Agentic-AI-Autonomous-Systems-Cloud-Payments-Telecom-OS-and-
Robotics
* https://github.com/sangmdas/DAS-Protocols-VII-Multi-Vault-
Technical-Non-Joinability-Reference-Implementation
* https://github.com/sangmdas/Secure-and-Privacy-Preserving-AI-
Interoperability-for-Third-Party-Tools
* https://github.com/sangmdas/Execution-Finality-Technical-
Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints
* https://github.com/sangmdas/Access-Is-Not-Egress-Precision-
Bounded-Location-Release-Reference-Implementation
Other Archived Publications
* "The Internet Solved Communication. It Never Solved Authority"
(Zenodo): https://doi.org/10.5281/zenodo.22082995
Author's Address
Sangam Kumar Das
Independent Inventor and Researcher
Balasore 756001
Odisha
India
Email: info@sangamdas.com
Das Expires 15 March 2027 [Page 114]