Confidential Serving
The mechanism scores routing on public benchmarks. Serving real users' requests through the same conductor is a different problem, because a user's prompt is private and nothing in the scoring path was built to keep a secret. This page is the design for that, its status, and what it inherits.
Status: designed, phased, not deployed for users. The hardware end of it is proven — on real Intel TDX machines, under the previous mechanism. The serving path exists and has been exercised. The two are not yet joined into a product, and nothing on this page should be read as an available API.
The architecture in one paragraph
A user encrypts their request to a public key that exists only inside an attested enclave, and the key's fingerprint is bound into the hardware quote, so the user can verify — before sending anything — that only an owner-approved image can decrypt it. The host relays ciphertext it cannot read. Inside the enclave the owner's image decrypts the prompt, hands the conductor only what it needs to decide, calls the chosen provider, encrypts the response to the user, and emits a signed receipt. The miner's model never touches plaintext it could exfiltrate, and no miner code runs at all. Validators verify by injecting encrypted probes indistinguishable from user traffic and grading the answers they already know.
Why the scoring path is not enough
The scoring mechanism's invariant — nothing the conductor writes reaches a worker — was built for benchmark tasks that are public anyway. Confinement stops the network; it cannot stop model behaviour that legitimately sees a prompt from encoding it into a legitimate call. The residual the previous mechanism documented at the top of its confinement module — prompt-based exfiltration through the sanctioned channel — was tolerable when the prompt was a public benchmark question and is fatal the moment it is a user's private request. Everything in the design follows from closing that hole: the conductor decides, the owner's measured image does everything that touches plaintext.
What it inherits, already built and hardware-proven
| component | state |
|---|---|
| real Intel TDX quote generation (configfs TSM) | working on GCP C3 |
| full DCAP verification — chain to the pinned Intel root, TCB status, CRL, QE identity | working |
report_data binding — 64 bytes of caller-chosen data inside the quote |
working |
MRTD + RTMR0/1/2 image identity (tdx.measurement_id) |
working |
| RTMR3 runtime measurement | proven under v2; code removed 2026-09-07 — to be rebuilt from the record |
| no-egress confinement (private netns, scrubbed env, stdio-only channel) | proven under v2; code removed 2026-09-07 — to be rebuilt from the record |
| on-chain approved-measurement governance | working (serve/governance.py) |
| reproducible measured image — byte-identical UKI → the same RTMR1, dm-verity rootfs | proven under v2; the v3 recipe (scripts/build_router_image.sh) descends from it |
| the serving path — OpenAI-compatible, ladder walk, metered cost | working, live-tested |
What it would give the scoring mechanism
The two things the trust model lists as not third-party-verifiable today — that the validator ran the model it admitted, and that the worker outputs are what the providers returned — are exactly what a measured image serving the conductor and metering the calls would make attestable. That is the reason this design is on the roadmap for the validator as well as for users.
What could kill it
Recorded rather than argued: TDX guest performance for a 35B-active-3B model at serving latency; the cost of a confidential-VM fleet against a revenue path that does not yet exist; and the fact that an attested image proves which code ran, not that the code is correct — the image is public and audited, and that audit is a human process.