Repository navigation
spec: define composite CPU and GPU evidence for confidential inference receipts #192
Description
Problem
Confidential inference can involve two independent hardware trust chains: a confidential CPU or VM and a confidential GPU. A generic runtime measurement or a GPU example alone does not define how a verifier establishes that both reports belong to the same workload, channel, model execution, and evidence epoch.
The evidence format should support this composition without claiming that a valid receipt proves model quality, physical isolation beyond the admitted hardware threat model, or inference correctness.
Scope
Define a generic TRACE profile or composition rule for confidential-inference receipts. No customer, event, provider deployment, or proprietary service is in scope.
Acceptance criteria
- Represent distinct CPU and GPU evidence chains and their independent appraisal outcomes.
- Bind both chains to one freshness challenge, deployment identity, or attested channel key.
- Bind the workload measurement, model artifact digest, policy identity, and inference-session identifier.
- Represent attestation-gated key release and lease state by digest or linked receipt, without exposing keys or model weights.
- Distinguish verified, structurally present but unverified, missing, stale, mismatched, and contraindicated evidence.
- Define verifier behavior for CPU substitution, GPU substitution, transport-key substitution, and expired lease cases.
- State explicitly that hardware evidence does not prove model output correctness or defeat physical attacks outside the admitted threat model.
- Add one positive and isolated negative conformance vectors for each required binding.
Related work
Weight Custody Manifest issue #77 tracks a real contemporaneous CPU plus GPU sealed-key release. This issue concerns the portable TRACE representation and verifier semantics for the resulting composite execution evidence.
Activity
lywinged commentedon Aug 26, 2026
I measured the v0.2 record shape against the acceptance criteria before answering.
What I cannot judge, said first. Nothing on the hardware side. Whether a shared nonce
across NRAS and a TDX quote is operationally achievable, what NRAS emits in practice, whether a
given binding survives hardware substitution: I have not built any of it and have no basis for
an opinion. Everything below is about the published schema and the spec text.
The v0.2 record assumes exactly one attested environment. Six places composite evidence
could have lived, and all six are closed:
runtimeplatform, onemeasurement, onenonce, onefirmware_versionappraisalstatus, oneverifierreferencesoriginkindother thanselfMUST carryruntime.platform: "software-only", and a verifier MUST reject otherwiselinked_call_id, so per tool call, and the section states the record's TEE measurement is unaffectedruntimeTwo of those are closed by normative language rather than by omission, so it reads as a decision
the spec took rather than a gap it left.
The enum makes it concrete.
runtime.platformis a closed list of ten values, and itcarries
intel-tdxandamd-sev-snpalongsidenvidia-h100andnvidia-blackwell. They sitthere as alternatives, not as components. A confidential-inference record on an H100 attached
to a TDX guest has to pick one and stay silent about the other, and
runtime.measurementis asingle hash constrained to
^sha(256|384):, so the second measurement has nowhere to goeither.
It also cannot be extended around.
additionalProperties: falseat the top level and onruntime,appraisal,origin,modelandreferences.items. The reference implementationagrees: every structural model is
extra="forbid",TrustRecordincluded. The oneextra="allow"isJWK, for RFC 7517 key-type variation.So the first criterion is not expressible as a profile over v0.2. It needs
runtimeandappraisalto become plural, which is a schema change of the same class as the one v0.2 namesas its single breaking change.
On the second criterion, the mechanism is already there, and I suspect the sixth is the
load-bearing one. §3.2.2 already specifies challenge-nonce binding: the verifier supplies a
nonce, the issuer echoes it in
runtime.nonce, and a record that omits or mismatches it MUSTbe rejected. Sharing one nonce across two attestations is the obvious extension and needs no
new mechanism. What a shared nonce establishes is that both quotes are fresh against the same
challenge. It does not establish that the GPU is the one attached to that CPU's guest, and
§2.2 puts the actor who exploits that squarely in scope: an operator with root, and an
orchestration layer that may substitute the workload it schedules. §2.4 does not exclude it
either. Whether a hardware primitive binds the two is the part I cannot judge.
Worth settling before anything is written against these criteria, because "define a profile"
and "make the record plural" are different pieces of work carrying different compatibility
costs.
imran-siddique commentedon Sep 3, 2026
Linking #279. Composite CPU and GPU evidence where one half is present and the other cannot be established is an instance of a primitive six threads here now need: a verifier result that is neither a pass nor a failure.
Relevant to this issue specifically, because the tempting shape is to report the composite on the strength of the half that verified. #260 is the precedent for the alternative: a named outcome carrying the reason, rather than a generic no-claim value that the next reader treats as fine.
#279
imran-siddique commentedon Sep 7, 2026
Composite CPU/GPU evidence still needs a schema/profile decision and hardware substitution evidence. The existing singular runtime/appraisal shape and a shared freshness nonce do not by themselves establish a bound composite. Coordinate hardware validation with agentrust-io/cmcp#537.
Jabsama commentedon Oct 22, 2026
A data point on the hardware side, since the thread notes nobody here had tried a shared freshness nonce across NRAS and a TDX quote. Disclosure: I run VoltageGPU, which rents confidential VMs.
It works, with one caveat. We publish bundles where one manifest, holding a 32-byte challenge drawn by the verifier, is bound to both chains: the TDX quote's
report_datais SHA-512(manifest) and the NRASeat_nonceis SHA-256(manifest). Our verifier (MIT, voltage-verify) appraises both chains offline and rejects a wrong challenge, one changed byte in the quote, and tokens re-signed under another key (itsselftestruns those mutations against a real bundle).The caveat, for your GPU-substitution criterion: a shared nonce shows that both reports were produced for the same challenge. It does not show that the GPU sits in that trust domain; the only link between the two chains is the manifest hash. We state that as a limit rather than claim it.
Public bundles and their limits: https://github.com/VoltageGPU/confidential-gpu-attestation-evidence