[Rats] draft-das-rats-frontier-model-extraction-02 — release control after attestation

[Sangam Das <[e-mail]>]

Subject: draft-das-rats-frontier-model-extraction-02 — release control
after attestation; is there a RATS work item?

Hello Team RATS,

I have posted an individual Informational draft and am looking for guidance
on whether any part of it belongs in RATS, and if so what the unit of work
would be:

https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/

This is not a DISPATCH/ART request and not a 3GPP or accelerator-ISA
proposal. I am asking only about attestation and appraisal semantics.

Problem
-------
RATS can establish that a confidential CPU/GPU or workload is in
an expected state (RFC 9334, EAT, device-assignment and cGPU EAR profiles).
AIR and AEP-style work can record that an inference or
action occurred.

A later question remains:

The environment is attested and the model has computed a result.
May this specific sensitive model artifact leave the protected
domain now?

Examples of artifacts more sensitive than ordinary completion text:
logits, full log-prob distributions, embeddings, hidden states,
KV-cache material, diagnostic traces.

Authentication and platform attestation do not, by themselves,
answer that per-release question. A missing AIR receipt also does
not stop the result from already having been returned.

One worked case
---------------
Participants:
M model owner / relying party
P evaluation partner (authenticated)
W attested serving workload on a confidential GPU
V RATS Verifier
S release boundary (logical Finality Sink: API egress, DMA,
or device egress — placement is implementation, not RATS)

Order and inputs:

1. M provisions W: model identity, policy "P may receive at most
100 high-resolution log-prob responses", extraction-state object,
security epoch.
Slow path may include platform attestation of W.

2. V appraises Evidence that W claims release-control is enabled,
extraction state is rollback-resistant, and the expected sink
class is active. V issues Attestation Results to M.
Input: Evidence. Output: AR. This step does not release SMI.

3. P sends privileged query n (n ≤ 100).
Input: partner identity, model, output class=logprobs.

4. W computes the log-probs inside the protected domain.
Result is a Candidate Release: not yet returned to P.

5. W checks current extraction state, epoch, destination, output
class, and remaining quota. If allowed, it atomically consumes
one unit (e.g. 99 → 100) and only then lets S emit the artifact.

6. Query 101: computation may still occur. No release authority.
S does not emit. Ordinary completion text, if separately
permitted, is out of scope of this quota.

7. Snapshot rollback of host software that reports "only 20 used"
does not restore quota if extraction state is outside that
rollback domain.

8. Replay of the authority for release 100 is denied.

What I am not asking RATS to standardize
----------------------------------------
GPU microarchitecture, HBM/DMA controllers, model formats, or a
new inference protocol. Those stay with vendors / other SDOs.

The RATS-shaped slice, if any, is a machine-appraisable statement
that the attested environment implements a named release-control
profile (enabled, policy/epoch, rollback-protected extraction
state, sink class, alternate-egress claim) so a Relying Party can
tell:

"the accelerator is authentic"
from
"the accelerator is authentic and claims to enforce the expected
protected release mechanism before SMI crosses the boundary."

The act-specific release decision stays local and is not an EAT.

Relation to current drafts
--------------------------
TDX/cGPU EAR — environment at session start; not per-release.
AIR — receipt after inference; missing receipt does
not prevent return of the result.
AEP — evidence that an action occurred under claimed
authority; not a fail-closed release gate.
Epoch markers — possible freshness input; not extraction quota.

The draft treats those as complementary, not as replacements.

Questions for the WG
--------------------
1. Is pre-effectuation release of sensitive model artifacts in
scope for RATS, or is it only local TEE/serving policy plus
ordinary attestation of the platform?

2. If any interoperable work is useful, should it be
(a) Informational architecture only,
(b) an EAT/EAR profile of release-control *capability and
state* claims (illustrative names are in the draft; no
IANA request in -02),
(c) reuse of existing EAT measured-component / epoch-markers
with no new profile,
(d) none of the above?

3. Does the WG see a remaining gap versus AIR and AEP, or is
"check policy then return logits" already covered?

4. If (b), should that profile live in RATS, or only as vendor
Evidence that Verifiers already know how to ignore?

I welcome the conclusion that existing mechanisms suffice.
Relevant IPR will be disclosed per BCP 79.

Draft:
https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/

Sangam Das