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 As frontier AI providers expose increasingly rich inference interfaces to partners, evaluators, and enterprise tenants, richer-than-normal outputs -- for example logits, log-probability distributions, embeddings, hidden states, intermediate activations, KV-cache material, and diagnostic state -- become practical extraction vectors rather than theoretical concerns. In this document, a "release" is any point at which such information leaves a provider's protected execution environment and becomes usable outside it, whether returned directly to a caller, cached, forwarded, or otherwise materialized. Existing authentication, confidential-computing, and remote-attestation mechanisms can establish important properties of the requester and execution environment, but they do not by themselves establish that each specific release of sensitive model information is currently authorized to cross that protected-to-unprotected boundary. This document describes that gap as a pre-effectuation release-control problem and proposes controls intended to limit unauthorized extraction and reduce the risk that released model information can be used for downstream distillation. It presents an execution-finality architecture in which computation is separated from authority to release. A sensitive result is treated as a Candidate Release, remains non-effective outside the protected domain, and becomes externally available only after release-specific validation, rollback-resistant extraction-state evaluation, bounded authorization, and verification at a controlled Finality Sink. The document discusses anti-bypass requirements, remote-attestation composition, latency, legacy deployment, industrial relevance, and a concrete model-extraction scenario. The mechanism is not claimed to prevent all forms of model distillation. Its narrower objective is to reduce unauthorized or excessive extraction of privileged model information that can materially improve model stealing, reconstruction, imitation, or distillation. Because release authority is bound to rollback-resistant, atomically consumed extraction state rather than to a bearer credential, the volume of privileged teacher signal an adversary can accumulate through the governed path is capped by authorized state transitions, not by request volume or attacker persistence alone.

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.

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

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.

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

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.

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.