What can these providers actually prove?

Every day we ask each confidential-inference provider for an attestation and check what it contains. A row is verified only when every layer that provider's architecture should be able to prove, it proves. Anything we could not reach is marked as such rather than scored — an unreachable endpoint is not a privacy finding. Methodology →

Coverage by target

Proven counts the layers this provider's shape is expected to prove — the expectation is set per architecture in REQUIRED_LAYERS_BY_SHAPE, and that bar is an editorial judgment, not a measurement. Different providers have different denominators, so compare the missing column, not the fraction alone.

How often does the attested code change?

Any client that pins an enclave measurement is betting the measurement holds still. It does not. Deploys counts transitions to a version string never seen before. Corrected accounts for deploys that begin and end between two probes: with T deploys seen over n−1 daily intervals the rate estimate is −ln(1−T/(n−1))/Δ.

Read revisits only on instance-sampled rows. There the version comes from whichever backend answered, so a return to an earlier value means we reached a different instance — Chutes' 19 revisits are one deploy plus a fleet that never finished draining, not 19 rollouts. On control-plane rows the version is read from a single document (NEAR from the gateway's compose, Tinfoil from the release feed), so it cannot show fleet structure at all and zero revisits there is guaranteed by construction rather than observed. Fleet size is not identifiable from once-a-day sampling on any row.

Per-layer detail

Cells: ✅ verified, ❌ rejected, ○ awaiting our review, — required but not exposed, — not applicable to this architecture. This matrix shows 10 of the 15 layers the probe records; the remainder are listed per row in the coverage table above.

Editorial notes

Hand-written, not computed, and therefore able to go stale. Each carries the date it was last checked against the data. Anything not on this list that you see above is machine-derived.

• 2026-08-18 Current RedPill uses ACI. The live tee.redpill.ai gateway scores Stage 0 even though all six ACI protocol checks now pass, including the strict production-OS appraisal — the deployment moved from the dstack dev image to prod 0.5.9 on or before 2026-08-18. Receipts verify end to end. Stage 0 rests on the legacy /v1/attestation/report, which ignores its model parameter and attests any name; public logs with raw upstream error detail; and an operator root-key input. api.redpill.ai shares the same attested keyset but is not TEE-only. A session audit accepted 163 of 237 records, rejecting only Chutes for missing evidence.
• 2026-06-18 Chutes' serving code is not measured. serve.py on the prompt-plaintext path is CFSV-excluded and in no RTMR, and the model name is not bound to the quote. A passing quote proves genuine TDX running a Chutes base image, not which model on which code.
• 2026-05-09 NEAR's gateway gap depends on the client. ALLOWED_COMPOSE_HASHES is unset server-side, so the gateway alone does not pin code. A closed-chain client that checks compose_hash against the on-chain set on Base closes it; a client that trusts the gateway does not.
• 2026-08-12 Some provider-adapter JWTs are decoded without signature checks. Phala's private-ai-verifier still passes verify_signature=False on NVIDIA and Intel Trust Authority tokens. This affects adapter conclusions derived from those tokens. The current ACI client verifies its gateway TDX quote through native DCAP.
• 2026-08-10 The bar is hand-set, and one entry was wrong. REQUIRED_LAYERS_BY_SHAPE is a hand-edited dict with no changelog. Venice's set excluded the two layers where its prompt-path exposure actually lives, so Venice scored a full row until an outside audit pointed at them; corrected 2026-08-10. Denominators still differ per architecture, so compare the unproven layers rather than the fractions, and treat the bar as editorial until it is derived from provider claims (issue #6).