Attestation-Bound Execution Finality for AI Accelerators and Confidential Workloads

Attestation-Bound Execution Finality for AI Accelerators and Confidential Workloads Independent Inventor and Researcher

Balasore Odisha 756001 India info@sangamdas.com

Remote attestation can establish evidence about the hardware, firmware, software, configuration, and execution environment associated with a workload. In heterogeneous confidential-computing environments, this trust assessment can extend across CPUs, confidential virtual machines, GPUs, AI accelerators, DPUs, SmartNICs, and other trusted execution components. An increasingly important class of workloads, however, does not merely compute data. AI agents and autonomous workloads can generate consequential operations such as API invocations, storage mutations, network configuration changes, infrastructure-control commands, financial instructions, device operations, and cross-workload requests. Successful attestation of the environment that generated such an operation does not, by itself, require that every subsequently generated operation acquire external effect. This document describes an attestation-bound execution-finality architecture in which a consequential operation first exists as a Candidate Act in a non-effective state. Before that act can acquire external effect, its relevant parameters are cryptographically bound to validation context that can include Attestation Results, workload identity, execution context, policy, authorization scope, freshness information, and other application-specific evidence. A designated Finality Sink verifies the required binding at or before the boundary at which the Candidate Act would first acquire external effect. The resulting separation is: trusted computation is not, by itself, act-specific authority. The architecture is intended to complement, rather than replace, Remote ATtestation procedureS (RATS), Entity Attestation Token (EAT) , workload-identity systems, confidential computing, Trusted Execution Environments (TEEs), accelerator attestation, and existing authorization mechanisms.

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 defines Evidence, Verifiers, Attestation Results, and Relying Parties. A Relying Party can use Attestation Results when making application-specific decisions, including authorization decisions. Composite attestation further permits trust assessments to incorporate multiple components of a heterogeneous confidential-computing environment. These mechanisms answer an important question: what properties can a relying party establish about the environment involved in computation? A distinct question becomes increasingly important as workloads become agentic: what causes one specific operation produced by that workload to become externally effective? Consider an attested AI workload that generates:

POST /payment destination = account-B amount = 50000 currency = USD Attestation may establish important properties of the CPU, GPU, confidential VM, firmware, software measurements, or other execution components. Those properties do not necessarily mean that the specific operation above should automatically be executed. The same observation applies to an AI workload generating:

DELETE production-database or:

modify_firewall(rule-X) or:

deploy(image-Y, production) or:

send(message-M, recipient-R) or:

open_valve(device-D, 80-percent) or:

transfer_control(workload-A, workload-B) The distinction is not between trusted and untrusted computation. The environment may be fully attested and operating exactly as intended. The distinction is between:

computation of a proposed operation; and
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 The design does not require a particular CPU, GPU, accelerator, TEE, cloud platform, network fabric, or authorization protocol.

Motivation

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
acting autonomously after initial authorization.

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 document does not specify a particular model architecture. It does not specify GPU instruction sets, tensor-processing semantics, accelerator scheduling, optical networking, Ethernet, InfiniBand, NVLink, or other transport technology. It does not replace remote attestation. It does not define a universal authorization policy. It does not require that validation occur in a hardware TEE. It does not require that the Finality Sink be colocated with the workload.

Non-Goals The following are explicitly outside the scope of this architecture.

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.

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.

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.

Mandating Hardware A deployment may use:

a TEE;
secure enclave;
HSM;
TPM-backed environment;
confidential VM;
DPU;
SmartNIC;
kernel enforcement;
hypervisor;
trusted gateway; or
combinations of these mechanisms.

The required property is enforcement of the non-effective-to-effective transition, not a particular implementation technology.

Terminology

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 A Candidate Act is not merely an abstract user intent. It represents the concrete operation proposed for effectuation.

Non-Effective State A Non-Effective State is a state in which a Candidate Act may be:

generated;
parsed;
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.

Execution-Finality Validator An Execution-Finality Validator (EFV) is a logical component that evaluates a Candidate Act together with relevant validation inputs. Inputs can include:

Attestation Results;
workload identity;
calling identity;
target identity;
execution context;
authorization scope;
policy;
jurisdictional information;
resource state;
operation arguments;
time;
nonce;
sequence state;
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.

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.

Execution Handle An Execution Handle (EH) is an optional scoped authorization artifact derived from successful validation. An EH can authorize execution of the corresponding Candidate Act subject to constraints encoded directly or cryptographically referenced by the handle. An EH SHOULD be:

act-bound;
audience-bound where applicable;
short-lived;
replay-resistant;
non-transferable where feasible; and
unusable for materially different operations.

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.

Architecture The basic architecture is:

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 The binding can be constructed over a canonical representation:

act_digest = HASH(canonical_candidate_act) Validation evidence can then conceptually bind:

validation_binding = { act_digest, workload_identity, attestation_reference, target, authorization_scope, issued_at, expires_at, nonce, policy_reference } 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 ) must not silently become authority for:

transfer( destination = B, amount = 100000 ) because the workload identity and execution environment remain unchanged.

Why Attestation Alone Is Not the Binding Consider the following lifecycle:

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 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.

Execution-finality binding therefore allows attestation to remain an important trust input while independently binding authority to the concrete consequential operation.

Relationship to the RATS Architecture 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 The proposed extension is therefore not:

RATS cannot authorize but:

RATS Attestation Result | v application-specific appraisal | + concrete Candidate Act | v act-bound finality authorization This allows existing RATS mechanisms to participate without making the Attestation Result itself a universal execution credential.

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 | | | +------------------------------------------+ Composite attestation can establish properties across those components. Execution finality addresses the later transition:

composite trusted environment | v compute | v Candidate Act | v act-specific validation | v Finality Sink | v external effect 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.

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" } The output is first represented as:

CandidateAct { action: "cloud.compute.delete_instance", resource: "production-47" } It remains non-effective. The validator evaluates:

workload identity + accelerator / platform Attestation Result + requested action + resource + tenant + policy + freshness If permitted, the validator produces validation evidence bound to:

HASH( "cloud.compute.delete_instance" || "production-47" ) 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.

Hyperscale Deployment A hyperscale deployment can place the architecture across existing infrastructure. Example:

GPU workload | Candidate Act | network fabric | API gateway [EFV + Finality Sink] | backend or at the destination:

GPU workload | Candidate Act + PVE | network | destination service [Finality Sink] The architecture therefore does not require adding validation processing to each accelerator interconnect packet.

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 Such a design can provide a hardware-separated enforcement point without requiring modifications to the model or accelerator instruction stream. However, this architecture does not require that a DPU or SmartNIC perform this function.

Network Fabric Considerations Execution finality is independent of network bandwidth and transport technology. A Candidate Act can traverse:

PCIe;
accelerator interconnects;
Ethernet;
InfiniBand;
optical networks;
service meshes;
QUIC;
HTTP;
RPC protocols; or
other transports.

The fabric answers whether information can be moved. Execution finality answers whether the consequential operation represented by that information is permitted to acquire effect. Accordingly, the architecture does not require per-packet authorization of ordinary data-plane traffic. Validation can occur only at security-relevant consequence boundaries.

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 A valid workload identity alone does not necessarily imply unlimited authority to perform every operation accessible to that workload. Conversely, an execution-finality system benefits from strong workload identity because the authorization evidence can be bound to the workload that generated or requested the operation. The architecture can therefore consume workload identities and workload credentials defined by systems such as WIMSE .

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.

Identity

Who or what is this workload?

Trust

What properties can be established about the environment? Remote attestation primarily contributes here.

Authority

Is this concrete operation permitted under the relevant identity, trust state, scope, policy, and context?

Finality

Has the required authorization been established at the boundary where the operation would acquire consequence?

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 For an RPC operation:

service method canonical arguments target For an infrastructure operation:

operation identifier resource identifier parameters tenant target environment 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.

Freshness Validation evidence should be bounded in time or transaction context when stale authorization would create security risk. Possible mechanisms include:

expiry timestamps;
nonces;
challenge values;
sequence numbers;
monotonic counters;
transaction identifiers; or
freshness claims inherited from an underlying protocol.

Long-lived execution evidence can undermine the act-specific property if it can be replayed outside its intended context.

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 A Finality Sink may maintain replay state where required.

Non-Bearer Properties A conventional bearer credential can confer authority primarily through possession. For high-consequence execution, a deployment may require stronger binding. An Execution Handle can therefore be bound to:

Candidate Act digest;
workload key;
workload identifier;
attested execution context;
target;
channel;
proof-of-possession key;
transaction identifier; or
combinations thereof.

The goal is to prevent extraction of a valid authorization artifact from becoming general reusable authority.

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 A system can contain multiple Finality Sinks for different consequence classes. For example:

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.

Hot-Path and Cold-Path Processing A practical deployment should avoid placing expensive operations on every consequential hot path. The architecture permits separation between: Cold-path operations

attestation verification;
endorsement retrieval;
certificate-chain processing;
policy distribution;
reference-value processing; and
long-lived trust-context establishment.

and: Hot-path operations

Candidate Act digest computation;
freshness verification;
context lookup;
policy decision;
proof verification; and
finality enforcement.

For example:

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:

Failure Modes

Validation Failure If required validation fails, the Candidate Act remains non-effective.

Missing Attestation Context Where policy requires an acceptable Attestation Result and no acceptable result exists, validation fails.

Expired Validation Evidence Expired evidence is rejected where freshness is required.

Parameter Mutation If security-relevant Candidate Act parameters change after validation, the original validation binding no longer authorizes the modified act.

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.

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.

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" without binding:

destination amount currency 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.

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.

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 The AI workload subsequently generates:

Candidate Act: POST /v1/infrastructure/deploy tenant = T1 image = model-service-v4 environment = production region = R1 The operation remains non-effective. The validator evaluates:

Candidate Act + Attestation Result + workload identity + tenant authorization + deployment policy + freshness 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 become:

Effective Deployment The confidential-computing environment establishes trust in computation. Execution finality establishes the controlled transition from computation to consequence.

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.

+-----------------------+ | CPU + GPU | | | | AI workload | +-----------+-----------+ | Candidate Act | v +-----------------------+ | DPU | | | | finality verification | +-----------+-----------+ | authorized | v data-center fabric 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.

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 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

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:

Candidate Act identification;
canonicalization;
act digest representation;
validation-evidence format;
workload binding;
attestation binding;
audience or target binding;
freshness;
replay protection;
error handling; and
cryptographic algorithm negotiation.

These details are intentionally left for subsequent protocol documents.

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 | | | Another deployment may have the Finality Sink request validation directly:

Workload Finality Sink EFV | | | | Candidate Act | | |------------------>| | | | validation request | | |-------------------->| | | | | | validation result | | |<--------------------| | | | | | effectuate | The architecture permits both models.

Why This Matters for AI Infrastructure Large AI systems increasingly transform model outputs into executable operations. At the same time, infrastructure is moving toward stronger hardware-rooted trust:

CPU attestation GPU attestation confidential VMs accelerator isolation DPU isolation workload identity service identity These mechanisms strengthen confidence in where computation occurs and which workload participates. Execution finality adds a complementary invariant:

a consequential output remains non-effective until the authorization required for that exact operation is established at its consequence boundary. This separates computational capability from consequential authority. In short: computation is not authority.

Operational Considerations Deployments should classify operations according to consequence. It is neither necessary nor desirable to apply expensive finality processing to every tensor operation, memory transaction, or network packet. Instead, enforcement can occur at semantically meaningful boundaries such as:

create delete transfer deploy publish send commit open release modify authorize This permits high-throughput accelerator and network fabrics to operate normally while protected consequences receive stronger authorization semantics.

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.

Open Questions The following questions are intentionally left open for IETF discussion:

Should an act-bound execution authorization be represented as a profile of an existing token format or as a new artifact?
Which Candidate Act canonicalizations are sufficiently generic for reuse?
Should the Attestation Result be carried directly, referenced by digest, or represented through derived trust context?
How should workload identity and proof-of-possession credentials be bound to execution-finality evidence?
Which components naturally perform the Finality Sink role in cloud and accelerator environments?
Can existing RATS conceptual messages be profiled for this use case without creating a new protocol?
Which parts belong in RATS and which are better handled by WIMSE or application-specific authorization protocols?
How should multi-verifier and composite-attestation results be represented in act-specific validation?
How should the architecture handle long-running agentic workflows in which authorization context changes between planning and execution?
Which mechanisms provide the lowest-latency implementation in GPU, DPU, SmartNIC, service-mesh, and hyperscaler environments?

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.

Normative References Remote ATtestation procedureS (RATS) Architecture Informative References The Entity Attestation Token (EAT) IETF EAT Work IETF Entity Attestation Token work. Workload Identity in Multi System Environments (WIMSE) IETF WIMSE Working Group IETF Workload Identity in Multi System Environments work. EAT Attestation Result (EAR) profile for Intel Trust Domain Extensions (TDX) + Confidential GPU (C-GPU) composite attestation Work in progress.

Appendix A. Architectural Summary The complete transition can be summarized as:

ATTESТED does not necessarily mean AUTHORIZED FOR EVERY ACT COMPUTED does not necessarily mean AUTHORIZED AUTHORIZED does not become consequential until the required finality boundary accepts the authorization.

Appendix B. Concise Statement for Discussion Remote attestation can tell a relying party important facts about the CPU, confidential VM, GPU, accelerator, firmware, software, or workload involved in computation. Workload identity can identify the workload making a request. Neither property requires a system to treat every future operation produced by that workload as automatically effective. This document explores a narrow interoperability question: Can an Attestation Result and workload identity be cryptographically bound to one concrete consequential operation, while that operation remains non-effective, so that a destination-side or infrastructure-side Finality Sink can verify the binding before permitting the external effect? The mechanism is intended to reuse existing attestation and identity infrastructure rather than replace it.

Appendix C. Technical FAQ and Anticipated Engineering Questions This appendix addresses technical questions likely to arise when considering attestation-bound execution finality in relation to RATS, WIMSE, confidential computing, AI accelerators, DPUs, SmartNICs, and hyperscale infrastructure.

FAQ 1. Isn't this already what a RATS Relying Party does? Question RFC 9334 already states that a Relying Party can consume an Attestation Result and use its own appraisal policy to make an application-specific authorization decision. Why is another execution-finality architecture necessary? Answer The proposed architecture does not change that RATS property. A RATS Relying Party can absolutely decide whether an Attester should be allowed to perform an operation. The narrower problem addressed here is whether the result of that decision is cryptographically and operationally bound to the exact consequential operation that eventually reaches the effectuation boundary. The distinction is:

RATS: Evidence | Verifier | Attestation Result | Relying Party | application-specific decision 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 The proposed property is therefore not simply "make an authorization decision" but: the protected external effect cannot occur through the protected path unless the authorization decision corresponds to this specific Candidate Act. A RATS Relying Party can be the Execution-Finality Validator, the Finality Sink, or both. The terminology is therefore intended to specialize an application of RATS rather than introduce an alternative attestation architecture. RATS relevance: direct. RFC 9334 already provides the Attester, Verifier, Attestation Result, Relying Party, Evidence, and appraisal concepts needed as inputs. WIMSE relevance: workload identity can provide the authenticated workload identity used in the Relying Party's act-specific decision.

FAQ 2. Is this simply AR4SI applied to individual requests? Question RATS already has Attestation Results for Secure Interactions. Why is an additional mechanism necessary? Answer AR4SI is highly complementary. AR4SI describes reusable information that allows a Relying Party to evaluate properties such as identity, trustworthiness, and freshness and then determine whether secure interaction should be allowed. Execution finality addresses a more granular operation: secure interaction permitted does not equal every subsequent operation permitted. For example, an attested AI workload might be permitted to communicate with a cloud-control service. During the same authenticated interaction it could generate:

GET /instances followed later by:

DELETE /instances/production-47 The secure-interaction trust state can remain valid for both messages while the authorization requirements differ substantially. Execution finality therefore permits:

same trust context | +------------------+ | Candidate Act B | different decision There is no requirement to repeat hardware attestation for every operation. RATS relevance: AR4SI can provide reusable trustworthiness inputs to the execution-finality validator. Current AR4SI work explicitly focuses on information provided to Relying Parties for decisions about secure interaction. WIMSE relevance: the authenticated workload associated with the secure interaction can be identified using WIMSE credentials while individual operations receive independent authorization.

FAQ 3. How does this interact with composite CPU, CVM, GPU, and accelerator attestation? Question A confidential workload may already produce composite attestation covering a CPU TEE, confidential VM, and confidential GPU. Why is Candidate Act validation separate? Answer Composite attestation and Candidate Act validation operate at different semantic layers. For example:

Intel TDX Evidence + Confidential GPU Evidence | v Composite appraisal | v Attestation Result 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 The important point is that the same successfully attested GPU environment can generate many different operations. For example:

Act 1 = read object X Act 2 = modify object X Act 3 = delete object X Act 4 = transmit object X to workload Y The attested environment can remain identical. The authorization decision need not. The current RATS TDX+C-GPU work from Microsoft, Intel, and NVIDIA is specifically concerned with establishing trust in a combined confidential VM and confidential NVIDIA GPU environment. That makes its Attestation Result a particularly natural input to the proposed architecture. The architecture also accommodates multiple Verifiers:

CPU Verifier --------\ \ GPU Verifier ----------> composed trust result / DPU Verifier --------/ | v Candidate Act | finality Current RATS work is separately examining multiple-Verifier topologies. RATS relevance: composite and multi-Verifier Attestation Results can feed finality validation. WIMSE relevance: after platform trust is established, WIMSE identifies the software workload operating inside that trusted environment.

FAQ 4. Does this require changes to GPUs, CPUs, tensor cores, or accelerator instruction sets? Question Would NVIDIA, AMD, Intel, Arm, or other chip vendors need to redesign accelerator hardware to implement this mechanism? Answer No architectural requirement in this document requires modifying tensor cores, GPU instruction sets, matrix engines, or accelerator scheduling. The architecture separates:

COMPUTATION tensor operation matrix multiplication inference model execution | v Candidate Act from:

AUTHORITY Candidate Act | validation | Finality Sink | external effect A deployment could therefore use an existing confidential accelerator unchanged. The enforcement component might instead reside in:

confidential VM DPU SmartNIC host TEE kernel hypervisor API gateway service mesh destination service 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. For example:

WIT: workload = ai-agent-47 can authenticate the workload. But the following operations are not equivalent:

read(database-A)

delete(database-A)

copy(database-A, external-domain-B) The proposed composition becomes:

WIMSE identity + Candidate Act + RATS trust state + policy | v act-specific decision | v Finality Sink Therefore, WIMSE answers primarily: which workload is presenting this credential, and can it prove possession? While execution finality asks: may this exact consequential operation become effective at this boundary under the current identity, trust, policy and context? RATS relevance: supplies trustworthy execution-state information. WIMSE relevance: supplies workload identity and proof-of-possession foundations.

FAQ 6. Why isn't an OAuth access token or down-scoped transaction token sufficient? Question Why not mint a narrowly scoped OAuth token after the concrete request has been generated? Answer That can be a valid implementation mechanism. This architecture should not claim otherwise. An OAuth authorization server could issue a sufficiently narrow per-operation credential containing or referencing:

actor resource operation arguments audience expiration transaction identifier If the Resource Server verifies it against the exact operation, then such a token could implement part of execution finality. The architectural question is broader: what invariant must be preserved regardless of the authorization artifact chosen? The proposed invariant is:

Candidate Act | | remains non-effective v act-bound authorization | v mandatory verification at consequence boundary | v external effect 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:

EH = Sign { act_digest, workload_id, target, audience, transaction_id, nonce, expiry, policy_context, proof_key } A stolen EH should therefore fail when presented with:

different Candidate Act different workload different target different proof key different transaction expired freshness state 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 An implementation may omit a separate Execution Handle entirely and have the Finality Sink query the validator directly. The architecture depends on the binding, not on the existence of a new token. RATS relevance: attested keys or key-binding mechanisms can strengthen the identity of the presenter. WIMSE relevance: WIMSE credentials already bind workload identity to cryptographic key material and therefore provide useful proof-of-possession foundations.

FAQ 8. Who creates the Candidate Act, and how is it canonicalized? Question If the AI runtime creates one representation but the destination interprets another representation, how can the authorization binding be trusted? Answer This is one of the most important protocol-design problems. The authorization must bind to the representation that determines the protected consequence. For an HTTP operation, security-relevant material might include:

method authority path selected headers body target resource For an RPC:

service method arguments target For a cloud-control operation:

operation resource ID tenant region parameters 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 ) 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:

be contained in the canonical Candidate Act; or
be independently constrained by the authorization context.

Otherwise parameter substitution is possible. The Finality Sink is ultimately authoritative regarding which canonical representation corresponds to the consequence it performs. RATS relevance: RATS does not need to define HTTP, RPC, payment, or cloud-operation canonicalization. WIMSE relevance: WIMSE identifies the initiating workload; application profiles define the operation being authorized.

FAQ 9. What technically makes a Candidate Act "non-effective"? Question Is "non-effective state" merely policy terminology? What prevents a compromised workload from bypassing validation and directly executing the operation? Answer The non-effective state must be enforced by architecture, not simply declared in metadata. For a protected consequence, every path capable of producing that consequence must pass a trusted enforcement boundary. For example:

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 If an attacker can bypass the Finality Sink and cause the same protected consequence through another path, then technical non-effectiveness has not been achieved. That should be stated explicitly as a security requirement: for a consequence claimed to be protected by execution finality, there MUST NOT exist an unmediated effectuation path available to the protected workload. This is the strongest distinction between an execution-finality architecture and a system that merely generates audit evidence. RATS relevance: RATS establishes trust-related facts; it does not automatically create this topology. WIMSE relevance: WIMSE can authenticate workloads traversing the enforced path, but workload identity alone does not remove bypass paths.

FAQ 10. How does the architecture prevent TOCTOU between authorization and execution? Question What prevents the operation from changing after it is validated but before the Finality Sink executes it? Answer The Finality Sink must verify the same security-relevant Candidate Act that was authorized. Suppose:

A = canonical Candidate Act H = HASH(A) The validator authorizes H. At finality:

H' = HASH(received Candidate Act) The Sink requires:

H' == H together with verification of the authorization evidence. Therefore:

resource version transaction epoch policy version expected state sequence number or the Finality Sink may need to re-evaluate those conditions atomically with effectuation. The strongest implementation is therefore: verify, consume authorization, and effectuate within one trusted transactional boundary. RATS relevance: freshness and Attestation Result applicability remain relevant but are not substitutes for operation-level TOCTOU protection. WIMSE relevance: workload identity remains bound to the operation but does not itself guarantee immutability of operation parameters.

FAQ 11. How are replay, duplication, and retry handled at hyperscale? Question Distributed systems legitimately retry requests. How can replay protection distinguish malicious replay from safe retry? Answer Replay resistance should not simply mean "reject the same bytes twice." The Finality Sink can use an idempotency or transaction model. For example:

transaction_id = 7F29... act_digest = H(A) max_effects = 1 expiry = T The Sink maintains:

(transaction_id, act_digest) -> state with states such as:

UNUSED IN_PROGRESS COMMITTED FAILED_RETRYABLE EXPIRED A network retry of a committed transaction can return the existing result without repeating the consequence. A different Candidate Act presented with the same transaction identifier is rejected. For operations legitimately allowing multiple effects, the authorization can specify:

max_uses sequence range rate limit resource set 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 No. The architecture should explicitly separate the cold path from the hot path.

COLD PATH CPU/GPU/DPU Evidence | v attestation verification | v Attestation Result | v cached trust context Then:

HOT PATH Candidate Act | digest | policy/context lookup | compact authorization | Finality Sink verification 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 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 Several identities can contribute to the decision:

initiating principal delegated subject Agent A workload identity Planner B identity Broker C identity Execution Service identity 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 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:

authenticated workload chain | v concrete Candidate Act | v act-specific authority | v Finality Sink

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:

Candidate Act | authorization | PVE / Permit / other artifact | v FINALITY SINK | verification required | v External Effect 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. 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 Execution-finality property:

Candidate Act | NON-EFFECTIVE | v authorization + validation | v Finality Sink | mandatory verification | v EFFECT 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:

RATS | platform Evidence | Attestation Result | v Candidate Act | validation | v Finality Sink | v External Effect | v AEP | auditable evidence This is potentially stronger than trying to replace the AEP work. RATS relevance: RATS establishes and composes trustworthy evidence about execution environments and increasingly about richer attestation contexts. WIMSE relevance: WIMSE identifies and authenticates the workloads participating in the action chain. Execution-finality contribution: defines the protected transition from a proposed operation to an externally effective operation and requires the authorization state to be load-bearing at that transition.

Summary: Relationship Between RATS, WIMSE, and Execution Finality The three layers can be summarized as follows:

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 The core architectural invariant is: successful computation does not itself constitute authority, successful authentication does not itself constitute authorization, and successful attestation does not itself require that every subsequently generated operation become externally effective. For protected consequence classes, the Candidate Act remains non-effective until the authorization required for that concrete act is verified at the boundary where the act would first acquire external effect.