Methodology
How this directory verifies confidential-inference providers
Everything below describes what the monitor does and what its results mean. Two rules run through all of it: a claim is only shown as verified when stored evidence supports it, and anything the evidence cannot support is shown as unknown.
How checks run
- Schedule
- One provider per hour (
OnCalendar=hourlysystemd timer), cycling round-robin through every configured provider before any repeats; the cycle position is persisted so independent timer launches continue it. A manual--only <slug>run never touches the cycle. - Runner
- A deployed Rust verifier binary (never compiled inside a timer), wrapped by
scripts/run-attestation-checks.js; each check is bounded by its own deadline, and every run appends to a SQLite history — results are never overwritten. - Evidence capture
- Raw evidence (quotes, certificates, TLS leaves, provenance responses) is stored content-addressed by SHA-256 next to each parsed decision, so any check page can link the bytes it was decided from.
- Change log
- Verdict changes are reconciled from the stored runs before and after collection, which is what the alerts feed and the changes API publish.
The evidence gates
Seven required gates are appraised per check. A check is end-to-end verified only when every required gate is verified on a fresh observation — an excluded (not-applicable) or unproven required gate keeps it incomplete.
| Gate | What must be proven |
|---|---|
| Hardware + TCB | Vendor-rooted quote and configured hardware policy both passed. |
| Freshness | Current evidence is bound to a verifier-owned challenge. |
| Confidential channel | A TLS or application encryption key is bound to the attested environment. |
| Workload identity | The measured runtime matches the expected workload configuration. |
| Source provenance | The measured runtime is linked to signed source or release evidence. |
| Request route | The request is cryptographically bound to the selected backend. |
What the statuses mean
- Verified
- Every required evidence gate is verified on a fresh observation (inside the 24-hour window, not future-dated).
- Partial / incomplete
- No required gate explicitly failed, but at least one was not proven, was not evaluated, or was excluded as not applicable. It does not imply that hardware verification passed.
- Failed
- An explicit mismatch or policy rejection was observed. The hardware quote may still be valid.
- Unreachable
- Fresh evidence could not be fetched — an availability failure, not proof the provider is outside a TEE.
- Stale / skewed / unknown
- The observation is older than the 24-hour window, materially future-dated, or unparseable; recorded verdicts are retained as dated history, never as current state.
What a TEE proves — and what it does not
- Proves
- Hardware-isolated execution rooted in a vendor trust chain, a measurement of the software that started inside it, and — when a channel gate passes — that a TLS or application encryption key belongs to that environment.
- Model weights
- Not proven unless a measurement covers them. A pinned workload measurement may or may not include the model weights; no tracked provider's stored evidence currently proves weight coverage, so this directory never claims it. Unmeasured workload identity stays "hardware only".
- Code quality
- Not proven. Software inside the TEE can still log, export, or leak prompts; measurements say what runs, not whether it is trustworthy.
- Request routing
- Not proven by a backend quote alone: a valid quote from one enclave does not show your request used it. Request-bound route receipts are appraised as their own gate, and router paths are labelled separately (see the router FAQ entry and the Route Explorer access-path flag).
- Physical attacks
- Not prevented and not detected by attestation — see the table below.
Known physical attacks on server TEEs
Peer-reviewed interposer attacks against the memory-encryption assumption of server TEEs. Listed because every provider's trust chain ultimately rests on these hardware roots; no tracked provider is claimed to have been attacked.
| Attack | Affects | Needs | Vendor position | Source |
|---|---|---|---|---|
| TEE.fail (Georgia Tech, Purdue, Synkhronix; Oct 2025)DDR5 memory-bus interposer (<$1,000, hobbyist parts) observes deterministic memory encryption. | Intel SGX / TDX (5th Gen Xeon) and AMD SEV-SNP with Ciphertext Hiding (Zen 5); attestation keys were extracted from machines in UpToDate status in some cases, and GPU workloads ran outside TEE protection while still passing NVIDIA CC attestation. | Physical access to the server. | Intel: out of scope for physical attacks. | tee.failpaper |
| Battering RAM (KU Leuven, Univ. of Birmingham/Durham; 2025)<$50 DDR4 interposer creates dynamic memory aliases at runtime. | Arbitrary plaintext read/write on Intel Scalable SGX and extraction of the SGX provisioning key; breaks SEV-SNP attestation on patched systems by replaying launch measurements. DDR4 only. | Physical access to the server. | Intel: out of scope; no CVE. | batteringram.eupaper |
| DDRop (KU Leuven, ETH Zurich, Durham, Google; disclosed 2026-09-14, ACM CCS 2026)<$200 DDR5 interposer drops memory writes; memory encryption has no freshness. | Intel TDX (forced debug mode and forged attestation / launch measurement on 5th Gen Xeon), Scalable SGX, and AMD SEV-SNP (EPYC Turin; copied victim pages). | Physical access + privileged software. | Intel: outside standard threat model. | ddropattack.eu |
All three need physical access to the server. Attestation can't detect them; this directory's checks can't either.
Reproducing a check
- Per check
- Every check page carries a "Reproduce this check" panel: the verifier challenge, observed and expected measurements, raw evidence downloads (content-addressed by SHA-256; credential-bearing artifacts are withheld with HTTP 403), and the run JSON for the stored run.
- Per run
- Every stored run is published as JSON at
/api/v1/attestation/runs/<runId>.json: the sanitized verifier policy, the targets, each parsed decision with its gates, and the verifier build that produced it. - Verifier CLI
- The CLI selects whole providers, not single checks:
node scripts/run-attestation-checks.js --only <provider-slug>(which invokes the verifier with--databaseand provider-level--only). That bare command is for your own checkout. On a host that also runs the scheduled collectors, run it through the maintenance lock so it can't overlap them:./scripts/run-maintenance.sh -- node scripts/run-attestation-checks.js --only <provider-slug>. - Source
- Verifier code: attestation-verifier on GitHub. The repository is currently private, so these links open only for people with access. Check pages link the exact module and commit that produced each stored result.