Reading TCB and Claims

A confidential response carries a fixed set of typed claims about the upstream that served it. They appear in the receipt’s upstream.verified.claims and in the attested session. A claim never just says “trusted”: each one states its own assurance level. This page is the reference for reading them. Each claim is an object with a status, a source, and a plain reason:

"tee_attested": {
  "status": "asserted",
  "source": "hardware_proven",
  "reason": "verified the TEE quote and bound the request channel"
}

Claim status

`status`	Meaning
`asserted`	The verifier’s evidence backs this claim.
`refuted`	The evidence contradicts the claim (for example a stale platform TCB). Recorded, not hidden.
`unknown`	The claim was not established. This is transparency, never a silent pass.

Claim source

The source states who vouches for an asserted or refuted claim, so a hardware fact and an assertion never look alike.

`source`	Assurance
`hardware_proven`	From the verified TEE quote or its collateral. Strongest.
`verifier_derived`	Computed by the verifier from verified evidence.
`provider_asserted`	Published by the provider, not independently proven.
`operator_asserted`	Declared by the gateway operator. Weakest.

The claim vocabulary

Claim	Asks
`tee_attested`	Is this a genuine CPU TEE with an identity bound to the channel?
`tcb_up_to_date`	Is the platform’s Trusted Computing Base current?
`os_known_good`	Does the OS or platform image map to reviewed source?
`serving_software_known_good`	Does the serving software map to reviewed source?
`gpu_attested`	Is a genuine confidential-computing GPU attested and nonce-bound?
`model_weights_provenance`	Are the served weights and quantization what they claim to be?

Which provider asserts which claim is on the Providers page.

TCB freshness

tcb_up_to_date is an honest tri-state read from the verifier’s reported TCB status:

An up-to-date platform asserts the claim.
A stale platform refutes it. The quote proves a stale TCB, so the gateway records the refuted claim rather than silently treating the platform as current.
An absent status is unknown.

Freshness comes from the verified evidence, never from policy.

How to read GPU attestation

gpu_attested becomes asserted (with source verifier_derived) when a provider’s NVIDIA confidential-computing GPU attestation is verified and bound to the verification nonce. It proves a genuine confidential GPU exists for that nonce. It does not prove that GPU is bound to the serving CPU TEE for your specific request. That is why its source is verifier_derived rather than hardware_proven, and why it never gates a session. Absent or unverified GPU evidence leaves the claim unknown.

Using claims in a decision

Require tee_attested to be asserted with source hardware_proven.
Treat serving_software_known_good: asserted as a stronger statement than a provider_asserted claim about software.
Decide your own policy on tcb_up_to_date: refuted (serve with a recorded stale TCB, or reject).
Read gpu_attested as supplemental, not as a gate.
Treat any unknown as “not proven”, and weigh it accordingly.

How It Works

Providers & Models

Trust

Reading TCB and Claims

Claim status

Claim source

The claim vocabulary

TCB freshness

How to read GPU attestation

Using claims in a decision

Next

Attested sessions

Providers

​Claim status

​Claim source

​The claim vocabulary

​TCB freshness

​How to read GPU attestation

​Using claims in a decision

​Next

Attested sessions

Providers

Claim status

Claim source

The claim vocabulary

TCB freshness

How to read GPU attestation

Using claims in a decision

Next