Beyond Attestation: An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive Frontier AI Model Information

Beyond Attestation: An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive Frontier AI Model Information Independent Inventor

Balasore Odisha India info@sangamdas.com

Security Remote ATtestation ProcedureS (RATS) remote attestation confidential AI frontier models model extraction model distillation execution finality confidential GPU Frontier and proprietary AI deployments may contain or expose model-related information substantially richer than ordinary final-answer text. Depending on the deployment and interface, such Sensitive Model Information (SMI) can include detailed probability information, embeddings, cached intermediate state, hidden representations, intermediate activations, diagnostic information, model-related metadata, or other high-information artifacts. Repeated unauthorized or excessive release of such information can increase the efficiency of model reconstruction, imitation, extraction, or distillation. Authentication establishes who is requesting an operation. Confidential computing and remote attestation can establish properties of the environment in which computation occurs. Neither property alone determines whether a particular pending release of particular model information, to a particular destination, under the current extraction state and security epoch, remains authorized to become externally usable. This document describes an execution-finality architecture for that remaining problem. Sensitive information may be computed while remaining a non-effective Candidate Release. External release occurs only after release-specific protected validation, evaluation of rollback-resistant extraction state where required, atomic reservation or consumption of bounded authority, and verification at a controlled Finality Sink. Release authority is bound to the applicable Candidate Release or bounded release class rather than operating as a generic transferable bearer credential. The architecture does not claim universal prevention of model extraction or distillation and does not restrict legitimately exposed ordinary model output. Its narrower objective is to make unauthorized, excessive, replayed, rolled-back, or bypassed release of protected model information technically harder to complete through governed release paths. RATS can complement this mechanism by allowing a Verifier or Relying Party to obtain machine-verifiable information about whether the expected release-control mechanism, protected state, security epoch, and Finality Sink are present and operating with the required assurance properties.

Introduction Frontier AI model providers invest substantial resources in training, alignment, evaluation, deployment, and operation of proprietary models. Protecting the resulting model material is therefore not limited to protecting model-weight files. High-information inference artifacts, internal representations, privileged diagnostics, and repeated high-resolution outputs can also have substantial intellectual-property and security value. The RATS architecture provides a model in which an Attester produces Evidence, a Verifier appraises that Evidence, and a Relying Party uses Attestation Results when deciding whether to trust an entity. The Entity Attestation Token (EAT) provides a framework for conveying attested claims. Current RATS work also addresses trustworthy assignment of accelerators , composite confidential-CPU and confidential-GPU attestation , and attested inference receipts . These mechanisms form important building blocks, but a separate question remains after a workload or accelerator has been authenticated and attested: is this particular release of sensitive model information authorized to become externally usable now? The central architectural principle of this document is therefore:

Computation is not authority to release.

A model may legitimately compute information inside a protected environment without that fact alone authorizing the information to cross an externally effective release boundary. OpenAI GPT-class and Anthropic Claude-class models are referenced in this document as recognizable examples of proprietary frontier-model deployments potentially affected by model extraction. No affiliation with, endorsement by, or implementation claim concerning these providers is implied. The architecture is vendor-neutral and applies to other frontier, enterprise, sovereign, scientific, and domain-specific AI models.

Scope and Non-Goals This document is an Informational problem-space and architecture document. It does not define a new EAT claim, COSE object, wire protocol, GPU instruction set, memory-controller design, or IANA registry. The document focuses on protected-to-unprotected release of sensitive model information. It does not claim universal prevention of model distillation. A party that is legitimately allowed to collect ordinary model responses may still use those responses as training material. The narrower target is unauthorized, excessive, privileged, replayed, rolled-back, or bypassed extraction of information whose release policy is intended to be more restrictive than ordinary inference output. This document does not replace authentication, authorization, RATS, confidential computing, anomaly detection, API quotas, watermarking, model-output minimization, or contractual controls. It describes an enforcement layer that can complement them.

Terminology This document uses the RATS terms Attester, Verifier, Relying Party, Evidence, Reference Values, Endorsements, and Attestation Results as defined by .

Sensitive Model Information (SMI): Model-related information subject to a release policy stricter than the ordinary public or tenant-visible inference interface. Depending on deployment, this may include weights, logits, log probabilities, embeddings, hidden states, intermediate activations, KV-cache material, training-related state, diagnostic outputs, reasoning-related traces when exposed by an implementation, or other high-information artifacts.
Candidate Release: A proposed transition by which SMI would become usable outside its currently protected domain. A Candidate Release is not yet treated as authorized external effect.
Release Authority: Bounded authority permitting a specific Candidate Release, or a narrowly defined class of releases, subject to validated scope and state.
Extraction State: Protected state relevant to repeated or cumulative release decisions, such as a counter, quota, accumulator, epoch, consumed-authority state, or equivalent rollback-resistant record.
Finality Sink: The first controlled boundary at which SMI can become usable by the intended external or less-trusted domain. A Finality Sink is a logical security role and need not correspond to one physical chip block.
Execution Finality: The property that an externally effective release occurs only after the applicable release authority and protected state have been verified at the relevant Finality Sink.

Problem Space

Model Extraction Is Broader Than Weight Theft An adversary does not always need direct access to a model-weight file. Repeated access to richer-than-normal inference artifacts may reveal behavior, internal representations, decision boundaries, model structure, or information useful for reconstruction and imitation. Potential extraction targets include full probability distributions, logits, detailed log probabilities, embeddings, hidden states, intermediate activations, KV-cache material, gradients where exposed, diagnostic state, high-resolution metadata, and large collections of strategically selected outputs.

The Trusted-but-Over-Authorized Case A difficult case arises when the requester is authenticated, the workload is legitimate, the accelerator is attested, and the requested computation is technically supported, but the requester is not entitled to export the requested quantity or category of SMI. Authentication identifies a principal; attestation establishes properties of an environment; neither fact alone necessarily grants final authority for every subsequent release.

Accumulation and Rollback Extraction risk can be cumulative. A single privileged output may reveal little, while thousands or millions of observations may create a valuable imitation or distillation corpus. Release decisions can therefore depend on previous extraction quantity, output class, model identity, requester, destination, security epoch, policy version, and consumed authorization state. If extraction state exists only in rollbackable software, an attacker may attempt to restore an older virtual-machine snapshot, restart a process, fork concurrent execution, replay a previous authorization, or otherwise cause the release path to observe stale state.

Alternate-Egress and Bypass A control located on only one API or memory interface is insufficient if equivalent SMI can leave through a different path. Relevant paths can include host-visible memory, DMA, PCIe, accelerator interconnects, peer-device transfer, debugger or diagnostic facilities, telemetry, shared memory, storage, and network-facing services. The architectural problem is therefore not merely to check a counter. It is to ensure that all controlled paths capable of converting protected SMI into externally usable information either traverse the applicable Finality Sink or remain technically subordinate to the same release decision.

Existing Mechanisms and the Remaining Gap

Authentication and Authorization Identity, workload credentials, API keys, access-control lists, role-based controls, and scoped authorization remain necessary. They can determine who may invoke a service or operation. The remaining question is whether the authorization is sufficiently bound to the exact SMI release, destination, extraction state, and security epoch at the point where external effect occurs.

Rate Limits, Quotas, and Output Minimization Rate limiting and limiting exposure of high-resolution outputs can reduce extraction opportunities. These controls can remain above the execution-finality layer. However, a service-layer quota does not by itself demonstrate that privileged local software, stale state, concurrency races, or alternate egress paths cannot bypass the intended restriction.

Monitoring, Audit, and Watermarking Monitoring, audit trails, behavioral detection, and watermarking can identify suspicious behavior or support attribution. Their security role is different when evidence is produced after the sensitive information has already escaped. The architecture in this document is pre-effectuation: the desired denial occurs before the controlled release becomes externally usable.

Confidential Computing and Platform Attestation Confidential computing can protect workloads and data against portions of the surrounding host environment. RATS can communicate and appraise Evidence about those environments. The trustworthy device-assignment work and the TDX plus confidential-GPU EAR profile illustrate current work for accelerators and composite confidential-computing environments. These mechanisms establish trust in the environment: that a stated accelerator, firmware, or composite platform is in an expected, measured state. They are evaluated at session or workload establishment, not at each candidate release of sensitive model information. This document does not compete with that layer; it consumes it. Platform attestation can be an input to Protected Validation (), but a favorable Attestation Result about the platform is not itself a statement that a specific pending release is currently authorized. Different deployment stages can also provide different assurance levels for the release-control mechanism itself. A software gateway can implement Candidate Release semantics, release-specific authorization, replay protection, destination restriction, and extraction-state accounting, but it cannot by itself establish the same alternate-egress resistance as enforcement located within an attested TEE, accelerator firmware, protected DMA or interconnect path, or silicon-backed Finality Sink. A RATS profile should therefore distinguish the presence of release-control semantics from the assurance class with which those semantics are enforced. A deployment should not represent a software-only gateway as providing hardware-backed alternate-egress closure merely because both implementations expose the same logical release-control interface.

Relationship to Inference Receipts and Action Evidence Two lines of current RATS-adjacent work address related ground and warrant explicit comparison, because a reader could otherwise reasonably ask whether this document is simply a policy gate bolted onto them. The Attested Inference Receipt (AIR) work defines a signed, attestation-linked artifact binding model identity, input/output hashes, and operational telemetry to a completed single inference, with a monotonically increasing sequence claim that lets a downstream verifier detect a gap. Application-layer action evidence work defines a signed action record binding an action, the authority under which it was taken, and its outcome, composed with platform Evidence for later verification by a Relying Party or Audit Consumer. Both are evidentiary artifacts: they are well-formed once the action or inference has already taken effect, and their value is realized by a party that consumes them afterward. Neither defines a mechanism whose absence, incompleteness, or failed verification prevents the underlying inference or action from occurring or from becoming externally visible through the ordinary response path. A missing AIR receipt does not, by itself, stop an inference result from being returned to the caller; an unverified AEP authority reference does not, by itself, stop the recorded action from having already occurred. Detection in these models is necessarily retrospective: sequence gaps and unresolved authority references are found by a verifier examining the record after the fact, not enforced by a gate the record must clear beforehand. This document addresses an earlier and narrower question: whether a specific proposed release of sensitive model information may become externally effective at all. Execution finality is a precondition on effect, not a description of effect after the fact. through define a decision that must succeed before the protected-to-unprotected boundary is crossed; failure results in no release through the governed path, independent of whether any receipt or action record is subsequently produced. This is the property named R1 and R7 in : computation is not authority to release, and failure to validate results in no protected external effect. Neither AIR nor the AEP composition model defines an equivalent fail-closed, pre-effectuation gate, and neither defines the rollback-resistant, cumulative extraction state (R3, R4) that this document treats as required once release decisions depend on prior releases rather than a single event. summarizes the distinction along the dimensions most relevant to a reviewer deciding whether this document duplicates existing work. Comparison Along Key Dimensions

Dimension	TDX/cGPU EAR Profile	AIR	AEP Composition	This Document
When evaluated	Session or workload establishment	At or after inference completion	After (or concurrent with) the action	Before the release becomes externally effective
What it establishes	Platform/environment is in an expected state	This inference occurred, bound to platform state	This action occurred under a claimed authority	This specific pending release currently has verified authority
Enforcement or record	Trust basis; not a release gate	Evidentiary record	Evidentiary record	Active gate; fails closed
Effect of missing or failed check	Attestation fails; unrelated to per-release effect	Receipt missing or gap detectable, after release already occurred	Authority reference unresolved, after action already occurred	Release denied; SMI does not cross the boundary
Cumulative or rollback state	Not addressed	Per-session sequence number for gap detection; not authority-consuming	Not addressed	Rollback-resistant, authority-consuming extraction state required (R3, R4)
Composability with this document	Consumed as input to Protected Validation	Can be emitted describing a completed, authorized release	Can record the Finality decision's outcome as an action	N/A

Receipts and action records therefore remain useful, and are not displaced by this document: they can supply audit trails, support attribution, and be composed with the Finality Sink's decision as their subject. But they are complementary outputs of, or inputs to, the release-control problem, not solutions to it. A Verifier that only appraises AIR or AEP artifacts can determine that an unauthorized release probably happened; it cannot itself have prevented that release from taking effect. Of the three, the AEP composition model is the closest adjacent architecture, because it already separates an action from the authority under which it was taken and records durable, composable evidence of that authority's use. It is not dismissed here as unrelated; it is the natural point of comparison. The distinction is narrower than "evidence versus no evidence": an AEP record can faithfully capture that a release occurred and under what claimed authority, and still be entirely consistent with that release having been unauthorized. Correct, complete evidence of an improper release is not the same artifact as a mechanism that kept the release from occurring. This document requires the latter for sensitive model information; AEP, by design, supplies the former.

Why This Is Not Merely a Policy Gate Added to Attestation Given the overlap discussed above, a reviewer could reasonably suspect that this document reduces to attaching an authorization check near an existing attestation or receipt flow. It does not, and the difference is falsifiable rather than rhetorical: a candidate design satisfies execution finality as defined in this document only if it survives the following tests, each grounded in the requirements of .

If the decision can be bypassed through an alternate DMA, API, debug, or peer-GPU route that does not traverse the same decision, it is not execution finality (R6).
If the extraction counter or state merely records activity without controlling whether release occurs, it is not extraction finality (R1, R7).
If authorization is checked upstream but the actual egress path does not independently enforce that authorization at the boundary, it is not Finality Sink enforcement (R7).
If a previously used authorization can be replayed, restored via rollback, or reapplied to a materially different output, destination, or epoch, it does not satisfy the release-finality property this document requires (R3, R5).

A design that adds an authorization check without closing alternate egress paths, without making the check load-bearing at the point of external effect, and without rollback and replay resistance on the state that gates cumulative release, is a policy gate in the ordinary sense already achievable with existing authorization and quota mechanisms (, ). It is not what this document describes, and it would not satisfy R1 through R7. Stated concisely: Evidence may establish what system ran, what authority existed, or what action occurred. Execution finality determines whether this particular sensitive model-state release is technically capable of becoming externally effective at all.

Execution-Finality Architecture The architecture separates the production of SMI from authority for that information to become externally usable.

Conceptual Release Flow

Candidate Release A Candidate Release represents a proposed externally effective transfer of SMI. It can commit to load-bearing attributes such as model identity, workload identity, requester or principal, output class, destination, quantity, policy identifier, security epoch, nonce, and applicable extraction state. The Candidate Release remains non-effective with respect to the intended external recipient until the release-control procedure succeeds.

Protected Validation The validator evaluates whether the proposed release remains within the applicable policy and current state. Deployment-specific inputs can include model identity, output category, requester, destination, cumulative extraction state, policy epoch, revocation state, and whether the same authority has already been consumed.

Rollback-Resistant Extraction State Where cumulative extraction matters, the architecture can use a hardware-isolated or otherwise strongly protected monotonic state, secure epoch, sealed state, protected consumption record, or equivalent mechanism. The required property is not a particular counter implementation; it is that restoring older application or virtual-machine state cannot recreate already-consumed extraction authority.

Conceptual Protected Extraction State 98 -> 99 -> 100 -> DENY prohibited rollback: 100 -X-> 20 ]]>

Rollback Resistance Does Not Require Per-Token Persistent Writes The requirement for rollback-resistant extraction state specifies a security property rather than a particular storage technology or update frequency. It does not require a hardware monotonic-counter, non-volatile-memory, remote-ledger, or other persistent write for every generated token or every internal model operation. An implementation may maintain protected state locally within an attested accelerator, trusted firmware, TEE, protected host-device boundary, or another enforcement domain and may use protected checkpointing, epoch transitions, sealed state, delegated bounded authority, batched state transitions, or another mechanism appropriate to the deployment. The required invariant is that crash recovery, software rollback, virtual-machine restoration, concurrency, or replay cannot recreate authority that has already been consumed. The granularity of durable state transitions is therefore an implementation and profile question. A future profile should specify the failure and recovery semantics required for its assurance class rather than require one persistence mechanism for all deployments.

Bounded Non-Bearer Release Authority Release authority should be bound to the Candidate Release or to a narrowly defined class of releases rather than operate as a generic transferable bearer credential. For example, authority for Model A, output class C, destination D, epoch E, and extraction state F should not automatically authorize a materially different model, output category, destination, or epoch.

Finality Sink The Finality Sink is the first controlled boundary at which SMI can become usable by the intended external or less-trusted domain. Depending on the implementation, it could be realized in accelerator firmware, protected DMA control, a memory or interconnect egress controller, a trusted device boundary, a TEE-hosted serving component, or another protected release mechanism. The defining property is not physical placement. It is that no controlled external release through the governed path becomes effective without successful verification of current release authority.

Desired Security Properties

R1 - Computation/Release Separation: Successful computation of SMI does not by itself authorize external release.
R2 - Release-Specific Binding: Release authority is bound to the load-bearing attributes relevant to the deployment, such as model, output class, destination, epoch, and extraction state.
R3 - Rollback Resistance: Already-consumed or advanced extraction state cannot be restored merely by rolling back ordinary software, process, container, or virtual-machine state.
R4 - Atomic Reservation or Consumption: Where a quota or single-use authority is involved, concurrent requests cannot independently consume the same final remaining authority.
R5 - Replay Resistance: A previously accepted release authority cannot be reused for a materially new Candidate Release.
R6 - Alternate-Path Closure: Equivalent protected SMI cannot become externally usable through an alternate controlled path that avoids the same release decision.
R7 - Fail-Closed Controlled Release: Failure to validate required authority or protected state results in no protected external effect through the governed release path.
R8 - Attestable Enforcement State: A remote Relying Party can, where the deployment requires it, obtain Evidence or Attestation Results sufficient to reason about whether the expected release-control mechanism and relevant security state are active.

Real-World Scenario Consider a frontier-model provider that runs a proprietary model on a confidential GPU cluster. An enterprise evaluation partner is authenticated and is permitted to query the model. For a limited evaluation task, the partner is also permitted to obtain at most 100 high-resolution log-probability responses. The partner is not authorized to obtain unlimited privileged model information.

Authorized Release Number 100 The protected extraction state records 99 previous privileged releases. The model computes another log-probability response. The result exists inside the protected domain but is treated as a Candidate Release rather than automatically returned. The validator checks the model identity, workload, output class, destination, authorization state, security epoch, and current extraction state. If all checks succeed, the remaining extraction authorization is atomically reserved, moving the protected state from 99 to 100. A release authority bound to the specific Candidate Release is then accepted at the Finality Sink, and the information becomes externally available.

Attempted Release Number 101 The partner submits another privileged request. The model may still compute the requested information internally. The validator now observes that the protected extraction allowance is exhausted. No valid release authority is produced. The important outcome is not that computation failed. The outcome is that the computed SMI remains non-effective outside the controlled boundary:

No valid release authority means no protected external release through the governed Finality path.

Snapshot Rollback An attacker restores an application or virtual-machine snapshot in which ordinary software reports only 20 previous releases. The protected extraction state still reflects 100. The stale application state therefore does not recreate extraction authority.

Replay An attacker replays the authority used for release 100. The Finality Sink or protected validator observes that the relevant authority is consumed, stale, or inconsistent with current extraction state and denies the release.

Concurrent Requests If two requests arrive while only one privileged release remains, atomic reservation or consumption permits at most one of the requests to advance the protected state. The other request observes the exhausted state and cannot independently reuse the same remaining allowance.

Alternate-Egress Attempt If an attacker attempts to export the same SMI through DMA, peer-GPU transfer, debugging, diagnostics, shared host memory, or another controlled interface, the architecture is complete only if that path is also governed by the Finality decision or cannot expose the protected information. An ungoverned equivalent path is an anti-bypass failure.

Relationship to Unauthorized Distillation Model distillation can use a higher-capability teacher model to produce supervision for a student model. Ordinary final answers can provide such supervision, but richer teacher signals can expose substantially more information about relative alternatives and internal representations. For example, a normal interface may return only the selected output, while a privileged interface may return a full probability distribution. Repeated extraction of full logits, detailed log probabilities, embeddings, hidden states, activations, or other privileged artifacts can create a substantially richer training corpus for imitation or reconstruction.

Unauthorized Extraction as a Distillation Path The architecture in this document attacks the first transition. If privileged information is computed but the specific release is not authorized, the Finality Sink denies external effect. The unauthorized party therefore cannot accumulate that protected teacher signal through the governed path. This does not prevent a party from training on ordinary outputs that the provider deliberately and legitimately exposes. The claim is narrower: extraction-control can reduce an important pathway by which unauthorized access to richer-than-normal teacher signals improves the efficiency, fidelity, or economics of model stealing, reconstruction, imitation, or distillation.

Operational and Implementation Questions

What Constitutes One Candidate Release? The architecture does not require one Candidate Release per generated token. Release granularity is deployment-specific and can correspond to one privileged API response, bounded streaming segment, tensor export, activation set, diagnostic object, batch, cached artifact, or another explicitly bounded release unit. The required property is that the authority accepted for one Candidate Release or bounded release class cannot silently expand to materially different model information, destination, release class, extraction state, or security epoch. Implementations may therefore select a granularity that preserves the required security property without imposing the strongest release-control operation on every internal token-generation step.

Does Every Release Require a Persistent Monotonic-State Write? No specific persistent-state mechanism is required by this architecture. Rollback resistance means that previously consumed release authority cannot be recreated by restoring ordinary software, process, container, virtual-machine, or other rollbackable execution state. Protected local state, sealed epochs, hardware-isolated state, bounded delegated authority, protected checkpointing, or other mechanisms may satisfy this property. A profile should define the required crash, rollback, and recovery semantics without assuming that every Candidate Release causes a physical non-volatile state write.

Can Release Decisions Be Batched or Amortized? Yes, provided that batching does not convert bounded release authority into unrestricted bearer authority. For example, protected validation may authorize a bounded class containing a specified model, requester, output class, destination, quantity, time or epoch constraint, and maximum extraction allowance. The Finality Sink or associated protected state must still prevent the bounded authority from being used outside those constraints. Batching is therefore compatible with execution finality when the batch itself has enforceable bounds and consumption semantics.

How Can Extraction State Scale Across Many Accelerators? This document does not require one globally contended counter shared synchronously by every accelerator. A deployment may partition extraction state by enforceable scope, delegate non-overlapping bounded allowances to individual enforcement domains, coordinate protected state through a trusted state authority, or use another protocol-specific distributed mechanism. The security invariant is that two execution domains must not independently recreate or spend the same unit of bounded authority. Where multiple accelerators share one logical extraction budget, the applicable profile must define how authority is partitioned, delegated, reconciled, consumed, or recovered after failure.

What Happens if Failure Occurs Between Reservation and Release? A production design must define the state of an authority when execution stops after reservation but before the Finality Sink can establish whether external effect occurred. Silently recreating the authority would permit double release, while permanently consuming every uncertain reservation could create unnecessary denial of service. Profiles may therefore define reservation identifiers, protected commit states, timeout rules, poison states, idempotent recovery, release acknowledgements, or other mechanisms appropriate to the controlled boundary. The fundamental requirement is that uncertainty must not silently recreate already-effective authority.

What Is a Destination for Purposes of Destination Binding? Destination is a security-domain concept rather than necessarily an IP address or hostname. Depending on the deployment it could be represented by a workload identity, tenant identity, cryptographic public key, protected channel binding, attested receiving environment, service identity, device identity, or another canonical identifier for the domain permitted to receive the Candidate Release. A profile should specify which destination representation is security-relevant and how it is bound to Release Authority. Mutable routing information alone may be insufficient where it does not uniquely identify the authorized receiving security domain.

How Can a Relying Party Trust an Alternate-Egress-Control Claim? A boolean statement that alternate egress is controlled is not sufficient by itself. Such a claim is meaningful only when it is derived from Evidence covering the enforcement components responsible for the relevant protected-to-unprotected paths and is appraised against suitable Reference Values, Endorsements, and Verifier policy. For example, an assurance statement concerning accelerator egress may depend on measured firmware, DMA configuration, protected interconnect state, debugger configuration, device assignment, and other deployment-specific components. RATS communicates and appraises Evidence about those components; it does not create enforcement that the measured system does not possess.

Where Must the Finality Sink Physically Reside? The architecture does not require one physical location. A Finality Sink is the first controlled boundary at which the relevant protected information can become usable by the intended external or less-trusted domain. Depending on the threat model and assurance level, the role can be implemented in an application gateway, TEE-hosted serving component, accelerator firmware, protected DMA controller, memory or interconnect controller, network egress mechanism, or dedicated silicon. Moving the sink closer to the physical egress generally reduces the number of components that must be trusted for alternate-path closure, but implementation location is not itself the architectural definition.

Why Is This Relevant to RATS Rather Than Only to Authorization? Execution finality contains both an enforcement problem and an attestation interoperability problem. This document does not ask RATS to decide model-release policy, maintain extraction budgets, or standardize GPU microarchitecture. The RATS-relevant question is whether an independent model owner, cloud customer, Verifier, or Relying Party can obtain machine-verifiable information establishing that the expected release-control profile is present, that the relevant enforcement components are in an acceptable state, that the expected Finality Sink and security epoch are active, and that the claimed assurance properties such as rollback protection or alternate-egress control correspond to the measured implementation. The act-specific Release Authority remains an enforcement object. Evidence and Attestation Results communicate properties of the environment enforcing that authority. The two roles should remain distinct.

What Makes Release Authority Non-Bearer? Possession of the authority alone should not be sufficient to authorize an arbitrary release. The authority is bound to security-relevant attributes of the permitted Candidate Release or bounded release class, such as model identity, release class, destination, extraction-state reservation, security epoch, nonce or equivalent freshness state, and applicable scope. A copied authority presented for a materially different Candidate Release should therefore fail verification. The specific cryptographic representation is profile-dependent; the architectural requirement is resistance to transferable, context-free use rather than use of one mandatory token format.

Does This Prevent All Model Extraction? No. The architecture governs identified protected release paths. It does not claim to prevent learning from ordinary outputs that a provider intentionally exposes, and it does not by itself eliminate side channels, covert channels, implementation vulnerabilities, compromised enforcement components, or information equivalence across an uncontrolled interface. The security claim is narrower: where model information is designated as protected and all relevant controlled paths are subordinate to the Finality decision, lack of valid current release authority prevents that information from becoming externally effective through those governed paths.

Performance and AI-Throughput Engineering Questions

Does Atomic Consumption Create a Global Serialization Bottleneck? No global serialization point is required by the architecture. Atomicity applies to authority that would otherwise be capable of being spent more than once within the same protected scope. A deployment may divide authority into non-overlapping protected allocations, shards, epochs, tenant scopes, accelerator-local allowances, or other independently consumable domains. A globally shared extraction policy therefore does not imply that every inference worker must synchronously update one global counter. The required property is narrower: two enforcement domains must not be able to spend the same bounded authority independently.

Must the Finality Procedure Execute on Every Token-Generation Step? No. Internal token generation, attention computation, expert routing, speculative decoding, sampling, and other model-compute operations need not individually constitute externally effective releases. Execution finality governs the transition at which protected information becomes externally usable. A deployment can therefore perform substantial computation internally and apply release control only at the selected externally effective release boundary or bounded streaming boundary.

Does Execution Finality Break Streaming Inference? It need not. A streaming response may be represented as a sequence of bounded release units rather than requiring the entire response to complete before any output is released. A profile may authorize an explicitly bounded stream, a sequence of chunks, a maximum quantity, an output class, a destination, and an epoch. The implementation may then consume that bounded authority incrementally while preserving the rule that information outside the authorized stream scope cannot be released merely because the stream has already begun.

Does the Architecture Interfere with Speculative Decoding? No architectural requirement applies release authority to speculative internal tokens merely because they were computed. Draft tokens generated by a proposer model, rejected speculative branches, and other internal intermediate results may remain entirely inside the protected computation domain. The relevant control point is the externally effective release of the accepted output or another protected artifact. This separation is an example of the architectural principle that computation does not itself constitute authority to release.

Does Release Control Prevent Microbatching and Continuous Batching? No. Candidate Releases belonging to multiple requests may be computed within the same accelerator batch. Release authorization is logically associated with the relevant release scope rather than with the scheduling unit used by the accelerator. An implementation may therefore preserve continuous batching, microbatching, request coalescing, and other throughput optimizations provided that release state and authority remain correctly isolated between principals, destinations, policies, and extraction scopes.

What Prevents Protected Extraction State from Becoming a Contended Hot-Path Data Structure? The architecture does not require all release decisions to share one state object. Protected state may be partitioned according to model, tenant, requester, release class, destination, epoch, accelerator, delegated allowance, or another enforceable scope. Profiles intended for high-throughput inference should choose a state model that minimizes unnecessary cross-request contention while preserving the required anti-replay, anti-rollback, and non-double-spend properties.

Does Every Release Require a Public-Key Signature? No. The architecture specifies bounded Release Authority semantics rather than requiring one cryptographic representation or one signature operation for every release. Depending on the trust boundary, implementations may use locally protected authenticated state, MAC-based mechanisms, protected handles, capability references, device-local keys, cryptographic commitments, or other mechanisms appropriate to the deployment. Public-key operations may be appropriate at trust-domain boundaries without being required for every internal fast-path decision.

Does the Design Add a CPU-GPU Round Trip to Every Sensitive Release? Not necessarily. Protected validation, state evaluation, authority consumption, and Finality Sink verification may be colocated in accelerator firmware, a confidential-computing domain, a protected host-device boundary, or another enforcement domain. The architecture does not require the GPU to synchronously consult an ordinary host process for each controlled release. Implementations should place the fast-path enforcement state sufficiently close to the release boundary to avoid unnecessary device-host transitions.

How Does the Architecture Interact with Tensor, Pipeline, or Expert Parallelism? Intermediate tensors crossing components of one protected model-serving domain do not automatically constitute external release. A deployment may treat a collection of GPUs, accelerators, chiplets, or protected services as one governed execution domain where the applicable threat model permits it. Execution-finality enforcement becomes necessary at the boundary where protected information would become usable by a less-trusted or independently authorized domain. A profile should therefore define the protected-domain boundary separately from the internal parallel-compute topology.

Does Mixture-of-Experts Routing Require a Finality Decision for Every Expert Invocation? No, unless an expert invocation itself crosses the deployment's protected-to-unprotected release boundary. Internal expert selection and tensor movement can remain model-compute operations within the protected domain. The architecture controls external effect rather than every internal computational dependency. This distinction is important for large sparse models in which many internal routing operations may occur for a single externally visible response.

What About Disaggregated Prefill, Decode, and KV-Cache Services? A distributed inference deployment may contain multiple protection domains. Transfer between prefill, decode, cache, and accelerator services is not automatically classified as external release; the classification depends on the applicable trust and authorization boundary. Where a transfer crosses into a less-trusted or separately authorized domain and contains protected SMI, that transition can become a Candidate Release. Where the components belong to one attested protected execution domain, internal transfers may remain subordinate to the same release-control mechanism without requiring an independent externally visible Finality event.

Does Autoscaling Require Global Re-Attestation or Re-Provisioning on Every Worker Addition? Not necessarily. Newly introduced enforcement domains need sufficient trust establishment and protected authority before participating, but existing workers need not stop processing while another worker is provisioned. A scalable deployment may provision bounded authority to independently attested workers or accelerator groups and revoke or expire that authority through the applicable epoch and state mechanisms. The exact delegation protocol is profile-specific.

Can Fail-Closed Enforcement Cause Head-of-Line Blocking or Service-Wide Outages? Fail-closed behavior applies to a Candidate Release whose required authority cannot be established. It does not require unrelated requests, ordinary outputs, tenants, models, or independent release scopes to stop. Implementations should isolate failure domains so that an unavailable state partition, expired authority, or uncertain reservation affects only the releases dependent on that state wherever possible. A profile should define degradation and recovery semantics explicitly rather than silently changing a failed protected release into an authorized one.

What Happens When Validation Cannot Keep Up with Model Throughput? The release-control stage is a bounded processing stage and can be provisioned, parallelized, sharded, or colocated according to expected protected-release volume. If demand exceeds its capacity, ordinary queueing and backpressure techniques may apply. The architecture does not permit overload to convert validation into default allow. A high-throughput profile should therefore specify capacity, queue, timeout, and overload behavior appropriate to the required availability and assurance level.

Can Verification Be Implemented in Existing Accelerator or Network Offload Hardware? Yes in principle. The architecture does not require Finality Sink verification to execute in a general-purpose CPU. Depending on the implementation, relevant functions may be realized in protected accelerator firmware, DMA or interconnect control, SmartNIC or DPU logic, memory-controller enforcement, a TEE, or another protected mechanism. The interoperability requirement concerns the security semantics and attestable assurance properties, not which vendor-specific execution unit performs the check.

Does Protecting KV-Cache or Other Intermediate State Require Copying It Through a Separate Gate? No architectural requirement mandates an additional copy. A Finality Sink is a logical enforcement boundary rather than necessarily a separate buffering device. An implementation may enforce release at an existing memory, DMA, interconnect, device, API, or network boundary. The required property is that protected state cannot become usable in the less-trusted destination without satisfying the applicable release decision.

What Performance Measurements Should an Implementation Report? A useful implementation evaluation should distinguish the slow path from the local release fast path and should measure at least protected-release throughput, added release latency, accelerator utilization, state-contention behavior, concurrency scaling, batching behavior, failure-path cost, and the effect of the chosen protected-state mechanism. Measurements should also identify the Candidate Release granularity and assurance class. A latency result for a software gateway is not directly comparable to a silicon-backed implementation, and a per-response release policy is not directly comparable to a per-stream-chunk policy.

Must Ordinary Inference Traffic Pay the Cost of Strong Extraction Control? No. A deployment may classify ordinary permitted inference output separately from privileged or extraction-sensitive information. Where policy permits ordinary output without the stronger protected-state transition, that output can continue to use the ordinary serving path. The strongest execution-finality mechanism can therefore be reserved for release classes whose confidentiality, extraction, destination, or cumulative-usage properties require it.

What Performance Properties Does the Architecture Intentionally Avoid Requiring? The architecture does not inherently require a remote attestation round trip per Candidate Release, a remote policy decision per token, a non-volatile write per token, one globally serialized extraction counter, one public-key signature per token, one CPU-GPU transition per token, or execution-finality processing for every internal model-compute operation. A profile that introduces any of those costs does so because of its chosen threat model or implementation strategy, not because execution finality requires them universally.

Adversarial and Threat-Model Questions The questions in this section are the ones a skeptical reviewer -- particularly an engineer at a frontier AI provider evaluating whether to adopt this architecture -- is expected to ask first. They are answered directly, including where the honest answer is a limitation rather than a resolved property.

Isn't Most Real-World Distillation Already Achievable Through Ordinary Outputs? Yes. Published and observed distillation of frontier models, including cases that received substantial public attention, has predominantly used nothing more than an ordinary completion or chat API: prompting the teacher model and training a student on the returned text. This document does not claim otherwise, and already excludes this case: a party legitimately allowed to collect ordinary model responses may still use those responses as training material, and this architecture provides no barrier to that. The narrower and more defensible claim is that richer-than-ordinary information -- full probability distributions, embeddings, hidden states, activations, and similar high-information artifacts -- can materially improve the efficiency, fidelity, or sample-economics of distillation relative to ordinary output alone, and that this specific privileged channel is the one this document controls. Where a provider's threat model is "prevent any distillation from any output," this document does not solve that problem, and no claim in this document should be read as suggesting that it does.

Doesn't Query-Efficient Black-Box Extraction Make the Threat Model Obsolete? Established model-extraction techniques, including equation-solving and active-learning-style attacks against the ordinary output interface, can in many cases reconstruct a functionally equivalent model using only ordinary query access, without ever touching logprobs, embeddings, or other privileged artifacts. Where such an attack is practical against a given model and interface, this document's mechanism does not detect, slow, or prevent it, because the attack never crosses a boundary this architecture governs. This document's scope is deliberately narrower: it addresses extraction whose efficiency or fidelity specifically depends on access to information beyond the ordinary interface. For model classes or deployments where black-box extraction from ordinary output alone is already sufficient, the privileged-release control described here reduces one additional pathway but does not address the underlying exposure, and a provider should not treat adoption of this architecture as evidence that black-box extraction risk has been mitigated.

What Prevents a Compromised Serving Process from Mislabeling a Privileged Release as Ordinary? This is a real gap if left unaddressed. The architecture assumes that the release-class attribute committed into a Candidate Release () truthfully reflects the category of information being released. If the component constructing that attribute is itself compromised, or is ordinary application code the attacker controls, it can label a privileged release as ordinary and route it through the unrestricted serving path, bypassing Protected Validation and the Finality Sink entirely. Applying stronger release-specific binding (R2 in ) after a release has already been misclassified does not help, because the misclassified release never enters the governed path. The required mitigation is that release-class determination, or an independent re-classification check, occur inside the same protected enforcement domain that performs Finality Sink verification, rather than being asserted once by ordinary, unprotected application code and trusted downstream without re-examination. A profile that allows classification to be set entirely outside the protected domain and merely trusted by it provides no stronger a security property than the label itself, regardless of how strong the downstream cryptographic binding is.

If Logprobs or Similar Outputs Are Already a Shipped Ordinary Feature, Isn't the SMI/Ordinary Boundary Just Wherever the Provider Draws It? Yes, and this is by design rather than an oversight. This document does not define Sensitive Model Information as an objective, universal category; defines it relative to "a release policy stricter than the ordinary public or tenant-visible inference interface," which is a deployment-specific policy choice. If a provider chooses to make full logprobs, embeddings, or another artifact an ordinary, unrestricted product feature, that is a business and product decision outside this document's scope, and the architecture has nothing to say about whether that decision is prudent. What the architecture is intended to assure is narrower: given wherever an operator's own policy draws the ordinary/privileged line, releases on the privileged side of that line actually go through governed validation and Finality Sink verification rather than being reachable through an unrestricted or inconsistently enforced path. The line itself is a policy artifact, not a technical one, and moving the line does not require re-architecting the enforcement mechanism.

How Does an Anti-Extraction Architecture Coexist With a Provider's Own Legitimate Distillation Product? Without contradiction. A provider that offers supported distillation -- for example, contractually permitting a customer to train a smaller model on a larger model's outputs -- is authorizing that specific release under its own policy. This document's architecture governs whether a release is currently authorized; it does not take a position on what a provider is permitted to authorize. An authorized distillation product is simply a release class that Protected Validation () is configured to allow for the relevant requester, destination, and scope, exactly as it would allow any other permitted release class. The architecture's target is release that is unauthorized, excessive relative to what was authorized, replayed, rolled back, or reachable through a bypassed path, not distillation as a business model. A provider can therefore operate a supported distillation product and this execution-finality mechanism simultaneously, with the mechanism enforcing the boundaries of what that product's own policy permits.

What About an Insider With Root or Physical GPU Access -- Doesn't That Bypass Everything? Yes, in general, and this document does not claim otherwise. A sufficiently privileged insider with host root, hypervisor-level access, or physical possession of the accelerator can typically read memory, intercept DMA traffic, or extract protected state through paths that a software-only or firmware-only enforcement mechanism cannot fully close. This is the same alternate-egress problem discussed in and R6 in , stated here explicitly as an insider-threat boundary rather than left implicit. The architecture's assumption is that the enforcement domain implementing the Finality Sink -- whatever assurance class a deployment chooses, from a software gateway up to dedicated silicon -- is not itself compromised by the party attempting extraction. Where that assumption fails, including a malicious insider with privileged access to the enforcement domain itself, this document's mechanism provides no protection, and no such claim should be inferred from adoption of this architecture.

If the Cryptographic Key Binding Release Authority Is Exfiltrated, Doesn't the Non-Bearer Property Collapse? Yes. The non-bearer property described in and R2 in depends entirely on the confidentiality of the key material used to bind and verify Release Authority. An attacker who exfiltrates that key -- through exactly the class of host or firmware compromise discussed in -- can forge Release Authority for any Candidate Release within that key's scope, at which point the authority functions as a bearer credential for practical purposes, regardless of how the binding was originally designed. This is why the architecture recommends binding keys to protected hardware roots such as device-local keys, TEE-sealed keys, or hardware-derived keys rather than ordinary software-held secrets, and why the accompanying software-only reference implementation () explicitly declines to claim rollback or alternate-egress assurance for exactly this reason. Key confidentiality is a precondition this document depends on throughout; it is not a property the architecture itself establishes.

What Is the Actual Overhead on a Production Inference Stack, Not Just the Reference Implementation? This is genuinely unmeasured by anything in this document. The accompanying reference implementation () measures only a local Python and SQLite path and explicitly disclaims relevance to GPU inference, TEE transition cost, DPU or SmartNIC throughput, protected DMA, or production distributed-inference performance. No benchmark exists anywhere in this document or its reference implementation for a production serving stack such as vLLM, TensorRT-LLM, SGLang, or a comparable system. A provider evaluating adoption should treat every latency and throughput question as open pending its own measurement on its own stack, and should not infer a production latency bound, an acceptable overhead percentage, or a throughput ceiling from anything published alongside this document. lists what a serious evaluation should measure once such testing is undertaken.

What Happens to Already-Granted Authority During an Active Incident -- Can It Be Revoked Mid-Flight? Authority already consumed and already delivered before a security-epoch advance cannot be recalled: execution finality controls whether a release can occur, not what happens to information after it has legitimately left the protected boundary. For authority not yet consumed, advancing the security epoch causes the next Finality Sink verification to fail for authority bound to the earlier epoch, consistent with the epoch-mismatch denial behavior described in and demonstrated in . The open question this document does not resolve is propagation latency: a design that caches authority validity for the duration of a long-running session or stream could continue honoring already-issued, now-revoked authority for the remainder of that session unless the streaming or session boundary itself re-checks the current epoch per chunk or per interval, as discussed in . This document does not specify a maximum revocation-propagation bound; a deployment intending to rely on epoch revocation as an incident-response mechanism must define and test that bound itself as part of its profile.

Can an Attacker Deliberately Exhaust Another Tenant's Extraction Budget as a Denial-of-Service? Yes. Extraction budgets and protected extraction state are themselves a resource, and any principal with authorized access to a shared extraction scope can, in principle, deliberately consume the remaining budget to deny legitimate use by another principal sharing that scope, or force excessive contention on protected state to degrade throughput for others. already notes this briefly; it is called out here directly because it is an obvious and easily overlooked consequence of introducing a shared, bounded resource as a security control. The mitigation is a deployment choice rather than something the architecture resolves on its own: extraction state should be scoped as narrowly as the deployment's isolation model allows -- per-tenant, per-principal, or per-model, as discussed in and -- so that one principal's traffic, malicious or merely careless, cannot exhaust a budget shared with another principal. A coarsely scoped or globally shared budget converts a security control into a new denial-of-service surface.

Why Would Any Single Provider Adopt This Unilaterally, Given It Is Pure Cost Unless Competitors Adopt It Too? Unlike security properties that only produce value when adopted broadly across an ecosystem, the specific problem this document addresses -- a legitimately authenticated partner or enterprise tenant over-extracting privileged information beyond what they were authorized to receive -- is a property of a single provider's own API surface, independent of what any other provider does. A provider can realize this benefit by adopting the architecture on its own deployment regardless of industry-wide uptake. What does depend on broader adoption is cross-provider comparability: a customer or regulator being able to verify, through the RATS attestation layer described in and , that comparable release-control assurance is present across multiple providers' deployments. This document does not claim that unilateral adoption by one provider yields that cross-provider comparability benefit, only the narrower, single-provider security benefit described above.

Relationship to RATS Execution finality does not replace RATS. RATS can provide the interoperable trust layer by which a remote model owner or Relying Party determines whether the expected release-control mechanism is present and operating in an acceptable state. A future profile could potentially expose claims or Attestation Results concerning release-control capability, policy or configuration identity, protected extraction-state mechanism, active security epoch, anti-rollback properties, or other assurance-relevant state. sketches illustrative claim semantics; this document does not request claim-number assignment or define a protocol. The distinction is:

Platform attestation asks whether the relevant execution environment is in an acceptable state.
Release finality asks whether this specific SMI release has current authority to become externally effective.
Receipts or action evidence can record what occurred and can be composed with platform Evidence for later verification.

Epoch Markers may be relevant where a deployment needs a shared freshness generation across distributed participants. The exact relationship between an Epoch Marker and protected extraction state is left for future work.

Concrete RATS Interoperability Profile for Model-State Release Control This section sketches how the release-control properties described in this document could be made remotely verifiable through existing RATS building blocks rather than through a new standalone attestation protocol. It supersedes the deferral in only to the extent of proposing illustrative claim semantics; it does not request claim-number assignment and does not define a protocol. The proposed approach is to represent release-control properties as claims in Evidence or an Attestation Result, using EAT-compatible claim semantics where appropriate, carrying such information in a CWT or equivalent structure, and protecting the resulting object using COSE mechanisms. The purpose of these claims is not to authorize model-state release directly. Their purpose is to allow a Verifier or Relying Party to determine whether the attested environment implements the required release-control properties before relying upon that environment. A possible architecture is:

Attestation Path for Release-Control Properties Evidence containing release-control claims -> Verifier -> Attestation Result containing verified release-control properties -> Relying Party ]]> The protected release path remains separate:

Protected Release Path Candidate Release -> Protected Validation -> Protected Extraction-State Transition -> Bounded Release Authority -> Finality Sink Verification -> External Release ]]> The distinction is important. The RATS object communicates evidence about the presence and state of the release-control mechanism. The bounded Release Authority remains the act-specific mechanism that determines whether a particular Candidate Release may cross the protected-to-unprotected boundary.

Candidate Release-Control Claims A future RATS profile could define claims semantically equivalent to the following. Candidate Release-Control Claims

Claim	Purpose
`release_control_profile`	Identifies the release-control profile implemented by the attested environment.
`release_control_enabled`	Indicates whether protected model-state release control is currently enabled.
`release_control_measurement`	Identifies or commits to the measured implementation of the release-control mechanism.
`model_identity`	Identifies or cryptographically commits to the protected model to which the release-control state applies.
`release_policy_id`	Identifies the active policy governing protected model-state release.
`security_epoch`	Identifies the current security or authorization epoch.
`extraction_state_id`	Identifies the protected extraction-state object or state domain.
`extraction_state_commitment`	Provides a protected commitment to the relevant extraction state without necessarily disclosing the raw counter or usage history.
`rollback_protection`	Indicates whether the relevant extraction state is protected against rollback, cloning, snapshot restoration, or equivalent state regression.
`finality_sink_id`	Identifies the protected Finality Sink or sink instance responsible for enforcing release.
`finality_sink_class`	Identifies the class of controlled boundary, such as accelerator egress, HBM controller, DMA controller, protected API egress, or network egress.
`destination_binding_supported`	Indicates whether release authority can be bound to a specific destination or receiving security domain.
`authority_consumption_mode`	Describes whether release authority is single-use, quota-bound, window-bound, state-consuming, or otherwise bounded.
`alternate_egress_control`	Indicates whether alternate protected-to-unprotected paths are subject to the same release-control decision.
`release_control_assurance`	Expresses the assurance level or implementation class associated with the release-control mechanism.

These names are illustrative and do not constitute requested EAT or CWT claim-number assignments.

Example Attestation Claim Set The following example is intentionally illustrative: A Verifier receiving Evidence containing these claims would not merely determine that a GPU or confidential-computing environment is genuine. It could determine that the measured environment claims support for a particular class of protected release enforcement. The Verifier could then produce an Attestation Result stating, for example, that:

the expected release-control implementation is active;
the expected model identity is present;
the current security epoch is acceptable;
rollback-resistant extraction state is supported;
the expected Finality Sink is present;
alternate protected egress paths are subject to release control; and
act-specific Release Authority is required before sensitive state may cross the controlled boundary.

CWT and COSE Carriage Where CBOR-based deployment is appropriate, the release-control claims may be carried in a CWT or another CBOR-based attestation structure. COSE can provide integrity protection, authentication, signatures, MACs, encryption, or combinations thereof according to the applicable deployment profile. This document does not require that the act-specific Release Authority itself be an EAT. A deployment may therefore use two distinct protected objects:

an attestation object establishing that the platform implements the required release-control mechanism; and
an act-specific bounded Release Authority that permits one particular Candidate Release or bounded release class to cross the Finality Sink.

Conflating these objects would weaken the architecture. Platform Evidence establishes properties of the environment. Release Authority governs the particular externally effective release.

Relationship to Epoch State The security_epoch claim allows a Verifier or Relying Party to determine whether Evidence or an Attestation Result corresponds to an acceptable current authorization state. An implementation may advance the security epoch when significant release-control state changes occur, including:

policy replacement;
model replacement;
revocation;
Finality Sink replacement;
extraction-state reset under an authorized maintenance procedure;
firmware or release-control implementation change; or
compromise recovery.

An act-specific Release Authority bound to an earlier epoch should not automatically remain valid after a security-relevant epoch transition. The epoch therefore provides a freshness and revocation domain, but it does not substitute for act-specific nonce, replay, consumption, extraction-budget, or Finality Sink state.

Privacy-Preserving State Representation A RATS profile should not require disclosure of sensitive operational information merely to prove that release control exists. For example, exposing an exact extraction counter could reveal:

customer activity;
model utilization;
tenant behavior;
privileged-query volume; or
internal security-policy thresholds.

The attested object may therefore expose a commitment, range, policy-state identifier, acceptable/not-acceptable result, or other privacy-preserving representation rather than the raw extraction value. A Verifier may validate the protected state internally and communicate only the minimum Attestation Result required by the Relying Party.

What RATS Would Standardize The proposed standardization target is therefore not a GPU microarchitecture, proprietary model-serving system, model-weight format, or vendor-specific extraction counter. The useful RATS interoperability surface is the machine-verifiable statement that an attested execution environment implements a specified protected model-state release-control profile, maintains required protected state and epoch semantics, and places the relevant externally usable release paths under an identifiable Finality Sink requiring current bounded release authority. This allows a model owner, cloud provider, confidential-computing platform, enterprise customer, or other Relying Party to distinguish "the accelerator is authentic" from the stronger property "the accelerator is authentic and is currently enforcing the expected protected model-state release-finality mechanism."

Latency and Performance Feasibility A practical model-serving system cannot require a remote attestation round trip for every generated token. The architecture therefore separates slower provisioning and trust establishment from a local release fast path. No universal latency figure is asserted. Performance depends on hardware, persistence model, concurrency, state-protection mechanism, evidence generation, and deployment policy. A standards document should specify interoperable semantics and assurance properties rather than assume a particular vendor's microarchitectural latency.

Slow Path The slow path can perform initial or periodic platform attestation, model registration, policy provisioning, workload authorization, key establishment, security-epoch initialization, and extraction-budget assignment.

Fast Path The fast path can remain local to the accelerator, trusted firmware, TEE, or protected host-device boundary. It can classify the Candidate Release, compare current protected state, validate locally provisioned scope, atomically reserve or consume authority, and release or deny without a network round trip.

Not Every Output Requires the Same Control Deployments can classify output types. Ordinary permitted completion text may use the normal serving path, while high-resolution log-probability requests, hidden-state export, activation dumps, or privileged diagnostics can use the stronger extraction-sensitive path. This avoids imposing the strongest state transition on every token where it is unnecessary.

Legacy and Incremental Deployment The architecture can be deployed in stages with increasing assurance.

Software gateway: existing inference services classify privileged exports and apply release-specific authorization, quotas, destination restrictions, replay protection, and logging. This provides useful semantics but weaker anti-bypass assurance.
TEE or confidential-computing enforcement: validation state and release decisions move inside an attested protected environment, reducing reliance on an untrusted host.
Accelerator or protected firmware enforcement: extraction state and release checks move closer to device egress, reducing driver and host bypass opportunities.
Silicon-backed enforcement: future accelerators may expose dedicated protected primitives for monotonic state, atomic consumption, model-bound state, egress verification, or release evidence.

Existing APIs need not change their externally visible function names. An operation such as ReturnLogProbs() can remain an application-level call while the implementation internally transforms it into Candidate Release, protected validation, Finality decision, and existing API response.

Industrial Relevance

Frontier-Model Providers Providers of proprietary frontier models, including systems such as OpenAI GPT-class and Anthropic Claude-class models, have direct incentives to protect model capabilities and privileged internal information. The architecture is especially relevant where selected partners, researchers, internal systems, evaluators, or enterprise tenants are allowed access to interfaces richer than ordinary end-user output.

Cloud AI Infrastructure A model owner deploying on infrastructure outside its physical control may want more than proof that the expected GPU and workload are present. It may also want verifiable assurance that the deployment enforces the owner's protected model-release policy before SMI can leave the trusted domain.

Accelerator and Semiconductor Vendors GPU, NPU, AI-accelerator, chiplet, interconnect, and confidential-computing vendors can potentially expose protected primitives for extraction state, release authorization, atomic state transitions, egress enforcement, and Evidence generation. This document deliberately avoids prescribing a specific silicon layout.

Enterprise and Sovereign AI Enterprises and sovereign operators may deploy proprietary financial, engineering, scientific, industrial, public-sector, or other high-value models in shared or outsourced infrastructure. Attestable release control can provide an additional mechanism for enforcing destination, workload, model, output-class, and extraction-state policies across administrative boundaries.

Potential Standardization Boundaries The IETF need not standardize an accelerator's internal silicon layout. The interoperable problem is how independent model owners, accelerators, cloud operators, workloads, Verifiers, and Relying Parties communicate and appraise the state relevant to protected release control. Potential future standardization work could define semantics for:

model or protected-artifact identity;
release class;
release-policy identifier;
extraction-state or consumption-state identifier;
security epoch;
destination binding;
release-control capability;
release-control assurance level; and
evidence that the expected protected release mechanism is active.

Existing EAT, CWT, COSE, RATS, and related mechanisms should be reused where they already provide the required semantics. New claims or containers should be proposed only after the working group determines that an interoperability gap remains.

Illustrative Release Decision The following pseudocode is non-normative and illustrates the state ordering intended by this document. It is not a prescribed implementation.

Non-Normative Release-Finality Pseudocode The pseudocode expresses security ordering, not required implementation stages, process boundaries, device crossings, memory transactions, or sequential hardware operations. An implementation may fuse, pipeline, cache, batch, or colocate these logical operations provided that the resulting system preserves the stated security invariants. A production design must specify crash recovery, reservation timeout, durable commit ordering, partial-failure semantics, multi-device synchronization, and whether a failed or uncertain dispatch poisons the associated authority. Those details are deliberately not hidden by the simplified pseudocode and require protocol-specific work.

Security Considerations The architecture is ineffective if sensitive information can leave through an ungoverned equivalent path. Implementations need an explicit inventory of protected-to-unprotected transitions and a closure argument for each relevant egress path. Threats include rollback, replay, concurrent double consumption, stale epochs, destination substitution, policy downgrade, authorization widening, compromised drivers, privileged-host compromise, malicious or vulnerable firmware, debugger and telemetry bypass, DMA bypass, peer-device transfer, state desynchronization, verifier compromise, attestation-key compromise, side channels, covert channels, and deliberate exhaustion of extraction budgets. Remote attestation cannot prove a security property that the measured implementation does not actually enforce. A release-control claim is useful only when the Attesting Environment can obtain trustworthy measurements or state from the components responsible for enforcement and when the Verifier has adequate Reference Values and appraisal policy. A monotonic counter alone is not an anti-distillation solution. If ordinary outputs or another interface expose equivalent high-value information, the attacker may simply change extraction path. Security analysis therefore needs to consider information equivalence and alternate paths, not only one counter or one API. Denial-of-service is also possible. An attacker may intentionally consume another principal's extraction budget or force uncertain dispatch state. Deployments should bind state to an appropriate scope and define recovery semantics that do not silently recreate authority.

Privacy Considerations Extraction-state and release-control Evidence can reveal sensitive metadata, including customer activity, model usage, business relationships, query volume, workload identity, destinations, and security policy. Evidence should disclose only the information necessary for the Relying Party's appraisal decision. Globally stable identifiers should be avoided where a less-linkable identifier can satisfy the deployment. Detailed extraction histories should not be exposed merely to prove that a limit has not been exceeded. Privacy-preserving appraisal and selective disclosure are desirable where compatible with the required security property.

IANA Considerations This document has no IANA actions.

IPR Note This document does not define licensing terms. Any IPR disclosures related to this Internet-Draft are handled through the IETF IPR disclosure process under the applicable IETF rules and are separate from the technical architecture described here. The primary broader, cross-industry presentation of the same execution-finality principle, published independently of this Internet-Draft series, is available at . For transparency, the author notes that the following published PCT/WIPO applications relate to the execution-finality architecture and associated technical concepts discussed across this Internet-Draft series:

WO 2026/150382 -- THE DAS PROTOCOLS --
WO 2026/150384 -- THE-DAS-PROTOCOLS-III --
WO 2026/150383 -- Systems and Methods for Preventing Artificial-Intelligence-Generated Hallucinations, Unsupported Outputs, Stale Outputs, and Unsafe Agentic Acts from Becoming External Consequences Using Candidate-Act Finality, Consequence Simulation, Escalated Conditional Finality, and Cryptographic Execution-Dependency Non-Completability --
WO 2026/150381 -- CVID / communication-governance publication --
WO 2026/172334 --
WO 2026/172336 -- Systems and Methods for Protected Execution-Finality Control Using Two-Instance Binding, Cross-Committed Validation Evidence, Scoped Non-Bearer Finality Authority, and Independent Finality Sink Reconstruction --
WO 2026/176422 -- Architecting Resilience for Enterprise AI: Preventing Data Reconstruction, Exfiltration, and Unauthorized Consequence in Compromised AI Environments --

This list is provided for transparency only and does not itself constitute the formal IETF IPR disclosure for this document. The author intends to file the applicable formal IPR disclosure(s) for this Internet-Draft separately through the IETF IPR disclosure process at a later time.

Conclusion Confidential computing and remote attestation can establish increasingly strong evidence about the environment in which frontier AI computation occurs. The next security question can arise after that trusted computation succeeds: whether a particular sensitive result is authorized to leave. This document frames unauthorized model-state extraction as an execution-finality problem. A workload can be authenticated, a GPU can be attested, and a model can successfully compute SMI while the external release remains unauthorized. By making the release a separate Candidate Act, binding authority to current protected state, preventing rollback and replay, enforcing the decision at the controlled Finality Sink, and making enforcement state attestable, deployments can reduce unauthorized accumulation of privileged model information. The intended rule is simple: compute does not imply release. Where protected model information is concerned, no valid release authority means no protected external effect through the governed Finality path.

References Normative References Remote ATtestation procedureS (RATS) Architecture The Entity Attestation Token (EAT) Informative References Entity Attestation Token (EAT) Measured Component Epoch Markers Work in Progress. An EAT Profile for Trustworthy Device Assignment Work in Progress. TDX and Confidential GPU EAR Profile Work in Progress. Successor to draft-kdyxy-rats-tdx-eat-profile, extended to cover confidential-GPU EAR claims. Title as filed pending final confirmation against the datatracker page. Attested Inference Receipt (AIR): A COSE/CWT Profile for Confidential AI Inference Work in Progress. Composing Application-Layer Action Evidence with Remote Attestation Procedures Work in Progress. The Internet Solved Communication. It Never Solved Authority Technical Architecture for Governing Consequential AI Agent Actions The Shift to the AI Control Plane: Securing the Frontier of Autonomous Action AI Hallucination Finality Layer: Preventing Unsafe AI Outputs from Becoming External Consequences Technical Blueprint to Deliver True Interoperability Without Ever Granting Unrestricted Authority, Europe's DMA Compliant Solution for Apple Siri Designing The HTTPS Layer for Agentic AI Governance: Verify Authority Before Execution A Compromised AI Server Must Not Become a Map of the Enterprise: Non-Joinable Vaults and Output-Release Finality Work in Progress. Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture Work in Progress. The Missing Execution-Finality Protocol Layer of the Internet Work in Progress. Technical Enforcement of the EU AI Act and Global AI Laws Without Relying on Paper Policies Work in Progress. Global Privacy Execution Enforcement Work in Progress. RATS Attestation-Bound Execution Finality Work in Progress. Preventing Unauthorized Adult and Age-Restricted Content Rendering to Children Through Hardware-Rooted Execution Finality Work in Progress. Map-Discovery Communication Finality Work in Progress. Query-Scoped Communication Handles for 6G Work in Progress. Digital Sovereignty Finality Work in Progress. RF Enable Is Not Transmit Authority: Finality for LEO/NTN and Inter-Satellite Control Work in Progress. Payment Execution Finality Work in Progress. Execution-Finality for AI-Native 5G/6G and O-RAN Work in Progress. Precision-Bounded Egress: Execution-Finality for Geolocation Disclosure Work in Progress. Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch Work in Progress. OT Actuation Finality Work in Progress. DAS Protocols for Enterprise AI Work in Progress. DAS Protocols: Candidate Act Finality Work in Progress. Agentic AI Tool Execution Finality Work in Progress. Hardware-Rooted National Control to Prevent Covert Intelligence Data Export and Unauthorized Frontier and Neural AI/Autonomous Acts in Critical Infrastructure Work in Progress. Execution-Finality-for-Protected-AI-Model-State-Release-RATS-Reference-Implementation Primary runnable reference implementation accompanying this document. Software version v0.1.0. DAS Protocols VII Multi-Vault Technical Non-Joinability Reference Implementation Supplementary reference implementation, accompanying [I-D.das-enterprise-ai-output-finality]. Secure and Privacy-Preserving AI Interoperability for Third-Party Tools Supplementary reference implementation, accompanying [I-D.das-execution-finality-ai-interoperability]. tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP Supplementary reference implementation, accompanying [I-D.das-agentic-tool-binding].

Reference Implementation: Provenance, Development Environment, Validation, and Limitations

Purpose of This Reference Implementation This appendix describes a runnable software reference implementation of the execution-finality architecture described in this document. The primary reference implementation for this document is published at . That repository was originally released alongside a companion document applying the same architecture specifically to two named frontier providers; because the underlying architecture is identical and vendor-neutral, the same implementation applies equally to this document. The purpose of the implementation is to translate the architectural security properties described in this document into executable, inspectable code so that engineers can inspect the state transitions, reproduce the allow and deny paths, test replay and rollback-related behavior, examine Candidate Release binding, test atomic consumption under concurrency, inspect Finality Sink verification, attack the reference implementation, and replace software components with stronger TEE, accelerator-firmware, DPU, SmartNIC, protected-DMA, interconnect, or silicon-backed implementations. This repository should therefore be understood as a reference implementation of architectural semantics, not as a production implementation of confidential GPU hardware or an implementation of any existing NVIDIA, AMD, Intel, Google, Microsoft, Amazon, Apple, OpenAI, Anthropic, or other commercial AI infrastructure. Three supplementary reference implementations accompany related documents in the same execution-finality series and are provided for cross-reference rather than as implementations of the architecture in this specific document: , which demonstrates the multi-vault Technical Non-Joinability architecture; , which demonstrates the AI-interoperability architecture under EU DMA Article 6(7); and , which demonstrates binding execution finality to Anthropic tool_use, OpenAI function calling, and MCP tools/call.

How the Implementation Was Derived The implementation was not obtained from proprietary source code, internal documentation, reverse engineering, leaked information, or access to any commercial AI provider's infrastructure. It was derived from the architecture expressed in this document. The implementation process was: identify the load-bearing architectural components described in the document; translate those components into explicit software objects; preserve the required ordering and security invariants; choose simple and auditable reference mechanisms for cryptographic binding and protected state; deliberately separate architectural requirements from implementation-specific hardware choices; write adversarial tests against the resulting state machine; and document the security properties that the software implementation cannot establish. The principal architecture translated into code is: The implementation therefore follows the architectural rule that computation is not authority to release. A model or other computation can successfully produce information while the information remains a Candidate Release that is not yet authorized to become externally usable.

Source-to-Code Mapping The implementation deliberately separates the major architectural roles into small Python modules.

Candidate Release and Load-Bearing Attributes Implemented principally in src/execution_finality/models.py. A Candidate Release contains the information that is proposed for external release together with security-relevant attributes such as model identity, workload identity, principal/requester identity, release class, destination, quantity, policy identifier, security epoch, nonce, and extraction-state scope. The Candidate Release payload and these attributes are cryptographically committed before Release Authority is issued.

Protected Validation Implemented principally in src/execution_finality/policy.py. The reference policy evaluates whether the Candidate Release is permitted for the configured model, principal, destination, release class, policy, and epoch. This is deliberately explicit rather than relying on an implicit default-allow branch.

Protected Extraction State Implemented principally in src/execution_finality/state.py. The reference implementation uses SQLite because it is widely available, easy to inspect, transactionally well understood, included in the Python standard library, and suitable for demonstrating concurrency and state-transition semantics. SQLite is not proposed as the production protected-state mechanism for frontier-model inference infrastructure. The reference state engine uses transactional operations, including an immediate write transaction, to prevent two concurrent callers from independently consuming the same final unit of authority. For file-backed operation it also enables: These settings improve software-level persistence semantics, but they do not transform SQLite into hardware-rooted anti-rollback storage.

Bounded Non-Bearer Release Authority Implemented principally in src/execution_finality/authority.py. The Release Authority is bound to a specific Candidate Release context rather than functioning as a generic bearer token. The authenticated fields include, among other things: Consequently, copying the Release Authority and attempting to apply it to a materially different Candidate Release causes verification to fail. Possession alone is therefore not intended to provide unrestricted authority.

Cryptographic Reference Mechanism Implemented in src/execution_finality/crypto.py. The reference implementation uses SHA-256 for Candidate Release commitments; HMAC-SHA-256 for Release Authority authentication; deterministic canonical JSON serialization for authenticated fields; and constant-time HMAC comparison through the Python standard library. This choice is deliberately simple. It demonstrates binding semantics, not a required production cryptographic profile. A production system could replace this mechanism with, for example, protected symmetric keys, device-local keys, asymmetric signatures, COSE structures, hardware-derived keys, TEE-bound keys, accelerator firmware keys, protected capability handles, or another profile-specific authenticated representation. The architecture does not require HMAC-SHA-256 specifically.

Finality Sink Implementation The Finality Sink is implemented in src/execution_finality/sink.py. In this software reference implementation, it is the first governed software boundary at which the Candidate Release payload is returned. Before releasing the payload, the sink independently checks authenticity of the Release Authority, the Candidate Release digest, model binding, release-class binding, destination binding, epoch binding, extraction-state scope, quantity, reservation status, the authority/reservation relationship, and the current protected security epoch. Only after those checks succeed is the corresponding authority transitioned to a terminal consumed state and the payload returned. This independent sink verification is important because upstream validation alone is not treated as sufficient authority for external effect.

Security-Epoch Revalidation During adversarial review of the implementation, an additional issue was identified. An authority could potentially be created under one security epoch and remain structurally valid even after the protected state had moved to a newer epoch. The Finality Sink was therefore strengthened to re-read the current protected extraction state at release time and verify that the authority still belongs to the current epoch. A regression test now verifies that: This implements the intended freshness/revocation relationship more accurately.

Programming Language The reference implementation is written in Python. Package requirement: Python >= 3.11. The package intentionally has no third-party runtime dependencies. It relies primarily on Python standard-library facilities including sqlite3, hashlib, hmac, json, dataclasses, threading, uuid, pathlib, tempfile, statistics, and time. This was intentional. Using a small standard-library-only implementation makes the security state machine easier to audit, run, modify, port, attack, and reproduce. Python was chosen for clarity and inspectability, not because Python is proposed for the production GPU inference hot path.

Development and Validation Environment The packaged repository was extracted into a fresh isolated execution environment and its complete unit-test suite was re-run. The validation environment used for that verification was: The execution environment was virtualized. The reported processor information should therefore be understood as information exposed to the execution environment, not as a hardware qualification or benchmark platform.

GPU and Specialized Hardware Used No NVIDIA GPU interface was exposed to the validation environment. Specifically, an NVIDIA GPU was not available to the test process. The implementation was therefore not tested on an NVIDIA H100, H200, B100, B200, GB200, Blackwell, Rubin, or another accelerator. It was also not validated on AMD Instinct hardware, Google TPU, AWS Trainium or Inferentia, Intel Gaudi, Apple Neural Engine, confidential GPU hardware, SmartNIC hardware, DPU hardware, FPGA, HSM, TPM-backed production state, protected DMA hardware, PCIe IDE, CXL security hardware, memory-controller enforcement, or custom accelerator firmware. No such hardware claim should be inferred from this repository.

TEE / Confidential-Computing Environment The software tests were not performed inside a production confidential-computing environment providing hardware assurance for the Finality Sink. The repository does not claim validation on Intel TDX, Intel SGX, AMD SEV-SNP, Arm CCA, NVIDIA Confidential Computing, confidential GPU composite attestation, a hardware-rooted monotonic counter, a production Trusted Platform Module, or a dedicated secure enclave implementing the release path. Accordingly, the reference RATS-style claims deliberately report: This is intentional. Reporting hardware assurance from an ordinary Python process would be misleading.

RATS Relationship The implementation is intended to demonstrate how the execution-finality mechanism could interact with the Remote ATtestation procedureS (RATS) architecture. Illustrative RATS-style release-control claims are implemented in src/execution_finality/rats.py. Example semantic fields include: These names are illustrative repository fields. They are not registered EAT claims, assigned CWT claim numbers, IANA registrations, or adopted IETF semantics. The repository does not define a new EAT profile. A future standards effort would need to determine which, if any, interoperable semantics belong in Evidence, Attestation Results, EAT/CWT structures, endorsements, reference values, or other RATS mechanisms.

Relevant Standards and Technical References The implementation was developed with reference to the architecture and references cited by this document, including (RATS Architecture), used as the architectural reference for relationships among the Attester, Evidence, Verifier, Attestation Results, Relying Party, Reference Values, and Endorsements; (The Entity Attestation Token (EAT)), relevant to the representation of attested claims; and RFC 10013, Entity Attestation Token (EAT) Measured Component, relevant to describing measured components in an attested system. The implementation was also developed with reference to , relevant to freshness and epoch-related state; , relevant to trustworthy assignment of accelerator/device resources; , relevant to composite confidential-computing environments involving CPU and GPU attestation; , relevant to attestation-linked inference evidence and explicitly distinguished from the pre-effectuation release-control problem addressed here; and , relevant to composing application action evidence with RATS.

AI-Assisted Implementation Provenance The software reference implementation was produced with assistance from OpenAI ChatGPT, GPT-5.6 Sol, by translating the architecture contained in this document into executable software components and then exercising those components with adversarial tests. AI assistance was used for architecture-to-code translation, state-machine construction, module decomposition, test construction, adversarial review, documentation, and packaging. The generated implementation was subsequently executed and tested rather than being provided only as unexecuted generated code. At the time of packaging, a freshly extracted copy of the repository completed 14 tests, 14 passed, 0 failed. However, successful automated tests do not constitute formal verification, independent security audit, production certification, proof of cryptographic security, hardware security validation, interoperability certification, or IETF approval. Human security review remains necessary.

What Was NOT Used to Produce the Code No claim is made that the implementation reproduces an internal architecture used by any specific frontier AI provider. The implementation was not derived from any provider's proprietary source code, NVIDIA firmware, NVIDIA confidential-computing source code, commercial cloud-provider source code, unpublished model-serving architecture, leaked implementation material, private API internals, proprietary GPU microarchitecture, or confidential corporate information. Names of companies or products in the accompanying architecture are examples used to explain the technical problem. No affiliation, endorsement, implementation claim, or confirmation by those companies is implied.

Test Coverage The supplied tests currently cover important architectural properties including:

Authorized release: a properly authorized Candidate Release can pass validation, consume bounded authority, pass Finality Sink verification, and become externally usable.
Budget exhaustion: a release is denied after the applicable protected extraction allowance is exhausted.
Destination substitution: authority for one destination cannot be used for another destination.
Security-epoch mismatch: a Candidate Release using a stale epoch is denied.
Epoch change after authority issuance: an otherwise-valid authority becomes unusable when the protected state advances to another security epoch.
Replay: a consumed Release Authority cannot be reused.
Payload modification: changing the payload after authority issuance changes the Candidate Release commitment and causes verification failure.
Attribute modification: changing security-relevant Candidate Release attributes after authority issuance causes verification failure.
Authentication tampering: modification of the HMAC-authenticated Release Authority causes verification failure.
Quantity enforcement: a Candidate Release cannot consume more extraction allowance than remains available.
Process restart: the file-backed SQLite demonstration shows that process restart does not automatically reset previously consumed state.
Concurrency: multiple concurrent requests competing for the final available unit of authority result in only one successful reservation.
Conservative recovery: authority can be returned to capacity only while the reservation remains in a state where the implementation has established that no external effect occurred.
Assurance honesty: the RATS-style claim generator is tested to ensure that the software reference implementation does not falsely advertise hardware rollback or alternate-egress assurance.

CI Configuration The repository includes a GitHub Actions workflow configured to test Python 3.11, Python 3.12, and Python 3.13 on GitHub's ubuntu-latest environment. The workflow checks out the repository, installs the package, runs the unit tests, and runs the demonstration program. This CI configuration provides portability checking once executed on GitHub. It should not be interpreted as GPU, TEE, firmware, or hardware validation.

Performance and Latency Disclaimer No benchmark in this repository should be used as evidence of production AI inference latency. The included benchmark measures only Python, SQLite, and local software execution. It does not measure GPU inference, TEE transition cost, confidential GPU performance, DPU performance, SmartNIC performance, protected DMA, HBM controller latency, accelerator firmware, silicon enforcement, or distributed inference clusters. The benchmark exists to detect obvious implementation regressions, make the reference path measurable, and allow engineers to experiment with alternative state backends. It is not a vendor benchmark.

Why the Reference Implementation Should Not Be Read as Requiring AI Slowdown The software modules represent logical security ordering, not mandatory physical pipeline stages. For example: reserve -> bind authority -> verify at sink -> release ]]> does not mean that a production accelerator must perform five remote operations, five device transitions, or five serial network requests. A production implementation may fuse operations, pipeline operations, colocate state and enforcement, batch bounded authority, pre-provision authority, shard extraction state, delegate non-overlapping allowances, use accelerator-local state, implement checks in firmware, implement checks in DPU/SmartNIC hardware, or perform verification at an existing DMA/interconnect/memory/network boundary. The required result is preservation of the security invariant, not preservation of the Python call graph.

No Mandatory Per-Token Finality Operation The architecture does not require every generated token to be treated as an independent Candidate Release. Depending on the deployment, a Candidate Release might represent a complete privileged API response, a bounded stream, a streaming chunk, a tensor export, a log-probability structure, a diagnostic object, a hidden-state export, a batch, or another protected information unit. Internal computation can therefore continue without treating every internal operation as an external effect. This includes, depending on the trust-domain definition, speculative decoding, rejected speculative tokens, attention computation, tensor parallelism, pipeline parallelism, Mixture-of-Experts routing, KV-cache movement, microbatching, and continuous batching.

No Mandatory Remote Attestation Per Release The architecture explicitly separates slower trust establishment from a local release fast path. Remote attestation may occur during initial provisioning, periodic re-attestation, accelerator assignment, model registration, policy provisioning, key establishment, or security-epoch initialization. The architecture does not inherently require a remote RATS exchange for every generated token or Candidate Release. The local fast path can instead consume trust and policy information established by the slower path.

No Mandatory Global Counter The SQLite implementation uses one local database because that makes the security behavior easy to understand. It must not be interpreted as requiring all GPUs in a hyperscale deployment to contend on one global SQL counter. A production implementation could use sharded state, per-tenant state, per-model state, per-release-class state, accelerator-local protected allowances, non-overlapping delegated budgets, hierarchical authority, distributed protected state, or another profile-specific mechanism. The required invariant is that the same bounded unit of authority must not be independently recreated or spent twice.

No Mandatory Persistent Write Per Token Rollback resistance is an architectural property. It does not inherently require a TPM write per token, an NVRAM write per token, a remote ledger update per token, or a database fsync per token. The reference SQLite backend prioritizes transparency over hot-path performance. A production design might instead use protected epochs, sealed state, hardware monotonic state, bounded delegated authority, protected checkpoints, firmware-resident state, secure memory, or another anti-rollback mechanism.

Major Limitations This section is intentionally explicit.

Limitation 1 -- No Hardware Alternate-Egress Closure The Python Finality Sink controls only release paths that actually invoke it. It cannot prevent a sufficiently privileged component from obtaining equivalent plaintext through an unrelated path. For example, this repository does not physically control host-visible memory, DMA, PCIe, peer GPU transfer, debug interfaces, accelerator diagnostics, telemetry, shared memory, storage, network interfaces, or firmware side channels. Therefore alternate_egress_control = false is the correct default claim.

Limitation 2 -- SQLite Is Not Hardware Anti-Rollback Protection The database survives normal process restart. That does not mean it survives an attacker who can restore an entire VM snapshot, a filesystem snapshot, an earlier disk image, or an earlier trusted-machine state. A production R3-strength implementation requires a stronger protected freshness or monotonic-state mechanism.

Limitation 3 -- Demo HMAC Key Is Not Production Key Management The demonstration uses a fixed development-only HMAC key. This exists solely to make the cryptographic binding reproducible. It must not be used as a production key. Production deployments require secure key generation, protected key storage, key rotation, authorization boundaries, compromise recovery, and potentially hardware-bound key material.

Limitation 4 -- Illustrative RATS Claims Are Not Real Evidence The software computes illustrative release-control claim fields. It does not currently produce a real EAT from a hardware Attester, issue a CWT, wrap the claims in COSE, interact with a production Verifier, use manufacturer Endorsements, retrieve real Reference Values, or perform remote attestation freshness verification. Consequently, rats.py demonstrates semantic mapping, not complete RATS interoperability.

Limitation 5 -- No Distributed Multi-Region Authority Protocol The reference implementation uses one local SQLite state domain. It does not solve production coordination among thousands of GPUs, multiple clusters, multiple regions, or independent clouds. A production profile must define how bounded authority is partitioned, delegated, synchronized, reconciled, revoked, and recovered.

Limitation 6 -- No Formal Exactly-Once External-Effect Guarantee The reference Finality Sink uses conservative consume-before-return behavior. This provides an at-most-once property for the governed in-process return path. If the process crashes after the authority becomes consumed but before the caller receives the result, the budget may be consumed without delivery. That is an availability cost. The implementation deliberately prefers that outcome over silently recreating an authority whose external-effect status is uncertain. A production network protocol requires explicit prepare, commit, acknowledgement, timeout, poison, recovery, and idempotency semantics appropriate to its actual external-effect boundary.

Limitation 7 -- Side Channels Remain Out of Scope This reference implementation does not eliminate timing side channels, cache side channels, power or electromagnetic side channels, covert channels, malicious firmware, compromised enforcement components, or equivalent information deliberately exposed through another interface. Execution finality governs identified release paths. It is not a universal information-flow proof.

Limitation 8 -- Ordinary-Output Distillation Is Not Prevented If a provider intentionally exposes ordinary inference outputs, a legitimate recipient may potentially use those outputs for training, imitation, or analysis. The architecture does not claim otherwise. Its narrower target is protected information whose release policy is more restrictive than the ordinary permitted interface.

Security Audit Disclaimer This repository should be treated as experimental security software. Although the tests exercise several important failure conditions, the implementation has not undergone an independent professional security audit. It has not been formally verified, fuzzed at production scale, subjected to hardware fault injection, certified under FIPS, Common Criteria evaluated, certified by an AI provider, certified by a GPU vendor, adopted or approved by the IETF, or evaluated as a production RATS profile. Researchers and implementers are encouraged to review the implementation critically and report replay weaknesses, race conditions, TOCTOU problems, authorization widening, state-recovery flaws, ambiguous external-effect boundaries, alternate-egress bypasses, cryptographic-binding errors, or unsafe deployment assumptions.

Standards Disclaimer This repository accompanies an individual Internet-Draft. An Internet-Draft is a work in progress. The existence of this implementation does not mean that the IETF has adopted the architecture, that the RATS Working Group has adopted it, that the IETF has approved the terminology, that any claim names have been registered, or that any proposed architecture is an Internet Standard. The implementation is intended to support technical evaluation and discussion.

Vendor Disclaimer References to specific AI providers, NVIDIA, GPUs, confidential computing, or other vendors and technologies are used solely to explain potential deployment contexts. This repository does not assert that any named organization uses this architecture, plans to implement it, has evaluated it, endorses it, is affiliated with the author, or provided source code or technical information for its development. The architecture and implementation are vendor-neutral.

Intellectual Property Disclaimer The repository demonstrates technical implementation concepts. Publication of source code should not automatically be interpreted as granting patent rights. Applicable IPR disclosures are handled separately under the IETF IPR process. Unless a separate license expressly grants rights, no patent license should be inferred merely from publication of the repository, ability to inspect the code, ability to execute the reference implementation, or inclusion of an Internet-Draft. Software copyright licensing and patent licensing are separate questions.

Reproducibility A minimal reproduction is: The implementation can also be executed without installation: A reference-only microbenchmark is available through: or: Its output must not be represented as GPU or production-inference performance.

Current Validation Result For the packaged v0.1.0 reference implementation, a fresh archive extraction was tested in the environment described in . Result: The passing tests establish that the specified software test cases behave as expected. They do not prove that all possible implementation bugs, attacks, concurrency states, hardware bypasses, or deployment failures have been eliminated.

Intended Next Steps for Stronger Implementations The Python implementation intentionally defines replacement boundaries. A stronger implementation could progressively replace components as follows: Future experimental implementations could therefore investigate Intel TDX, AMD SEV-SNP, Arm CCA, confidential GPU attestation, accelerator-local protected state, DPU/SmartNIC enforcement, protected DMA, hardware key binding, COSE-protected Release Authority, real EAT Evidence, RATS Verifier integration, multi-GPU delegated extraction budgets, hardware-backed epoch state, protected stream release, and a high-throughput accelerator-local Finality Sink implementation. Each stronger implementation should advertise only the assurance properties that can actually be demonstrated.

Summary This appendix demonstrates that the execution-finality architecture can be expressed as a concrete executable state machine in which computation does not equal authority to release. The current repository demonstrates a Candidate Release together with explicit protected-policy evaluation, state-dependent bounded authority, atomic reservation, cryptographic candidate binding, replay resistance, epoch revalidation, independent Finality Sink verification, and fail-closed governed release, using an auditable Python/SQLite implementation. It does not demonstrate hardware-enforced alternate-egress closure, hardware anti-rollback, confidential GPU enforcement, production RATS Evidence, production hyperscale performance, formal verification, or vendor adoption. That distinction is intentional. The repository is intended to give engineers a concrete implementation that can be run, inspected, criticized, attacked, and progressively replaced with stronger protected enforcement components without confusing a software demonstration with production hardware assurance.

Acknowledgements The author welcomes review from the RATS, confidential-computing, AI-security, accelerator, and protocol-security communities, particularly on whether the proposed pre-effectuation release-control gap is already covered by existing mechanisms and where interoperable attestation semantics would be useful.