Privacy tiers

Every request executes under one of three tiers. The default comes from the API key; you can override per-call with the sable_privacy_tier body field.

# Pin a request to a specific privacy tier.
resp = client.chat.completions.create(
  model="saxeo-confidential-qwen3.6-35b",
  messages=[{"role":"user","content":"Summarize this filing"}],
  extra_body={"sable_privacy_tier": "confidential"},
)

The confidential and sovereign tiers route to the attested path, so they only accept the confidential models. Requesting any other model on those tiers fails closed with a 400, never a silent downgrade to a plaintext host. The one exception is the flagship lane: saxeo, sable-fast, and sable-max called on the confidential tier route to the attested confidential models instead of being refused, with the receipt keeping the requested id and recording the engine and attestation.

The honest version, tier by tier

standard is encrypt-in-transit. The request is decrypted at one auditable egress frame and sent to a model host that runs it and sees the prompt. You still get: no prompt or completion stored anywhere, logs that hold only metadata, a signed receipt, and a region pin this deployment either honors or refuses, never quietly ignores. The host seeing the prompt is the limit of what software isolation can promise, which is why confidential exists.

confidential is live for saxeo-confidential-qwen3.6-35b and saxeo-confidential-gemma4-26b. Those models run inside an attested Intel TDX enclave on an attested backend. Before routing, the gateway cryptographically verifies the enclave's TDX quote against a pinned measurement. That result is stamped into your signed receipt as an attestation block (verification: "tee-attested"), so you can confirm, yourself, that your request was routed to a real enclave the host could not see into. A confidential request for a model we can't attest is refused, never silently downgraded to a plaintext host.

The receipt's response_bound flag is the stricter, per-response claim: the enclave signs sha256(request):sha256(response) with the key committed in its quote, and the flag may only be true when that signature verifies and both digests match the bytes this gateway sent and received. It reads false on every receipt this deployment issues today — the check needs the raw response bytes and the chat handlers do not yet hand them to it, so the gateway declines to make a claim it cannot substantiate. Read an attested receipt as "routed to a verified enclave", not yet as "this exact answer came from it".

What the pinned measurement covers

A TDX quote carries several registers. Two matter here: MRTD, the measurement of the confidential VM's base image (firmware, kernel, initrd), and RTMR3, which measures the workload running inside it. Only the register that matched the pin reaches the receipt: under this deployment's MRTD pin, measurement and mrtd carry the same MRTD value and RTMR3 is not on the receipt at all. If you need the workload register, read it from the live quote via GET /v1/attestation.

This deployment currently pins MRTD. So a passing check proves the request reached a genuine Intel TDX enclave, running the expected base image, with an up-to-date TCB, whose bound key signed the response. It does not pin the specific workload build.

The reason is measurable rather than theoretical. Our attested backend serves from a pool of enclaves, and a census of its quotes found three distinct RTMR3 values against a single unchanging MRTD. Pinning one workload value therefore only verifies when the load balancer happens to route to that instance, which produced repeated silent outages. Pinning the base image is stable and honest about what it proves. If you need workload-level pinning for a compliance requirement, ask us and we will pin the RTMR3 set for your traffic and accept the rotation cost.

One related consequence, stated plainly: gpu_verified is reported, not required. On integrated-attestation backends the GPU's confidential-computing configuration is measured as part of the workload, so under an MRTD pin it is recorded rather than proven. Do not read the confidential tier as a GPU-CC guarantee today.

One operational consequence of the fail-closed rule, stated plainly: if the backend's base image is rebuilt upstream, its MRTD changes, and the gateway refuses confidential requests (HTTP 502, attestation_failed) until we verify the new build and re-pin. During such a window standard traffic is unaffected; the confidential tier's live posture is always visible on GET /v1/status and GET /v1/attestation. Build agents that use this tier to handle a 502 by retrying later, not by falling back to standard silently (that decision should be yours, not ours).

What's still ahead: more confidential models, and moving the enclave from an attested third-party backend to hardware Saxeo measures itself (so the trust root is our binary, not the backend's attestation). sovereign adds jurisdiction pinning on top, and the refusal half of that is real today: a region pin is honored only when it matches the region this deployment declares it runs in, refused with a 400 otherwise, and the region that ran is signed into the receipt. What a single-region deployment cannot do is honor a pin for anywhere else. Serving several regions takes more than one deployment, which arrives with the fleet (not yet built).

Closed, vendor-hosted models are a harder limit. Anything with open_weight: false in /v1/models, like OpenAI's gpt-4o-mini, is standard tier only: it runs on the vendor's own servers, so encrypt-in-transit is as far as its privacy can ever go.

One distinction worth keeping sharp: vendor-hosted models are reached through Saxeo's own upstream account, so the vendor never learns who asked (no caller identity, key, or payment details), but its infrastructure still sees what was asked. That anonymized access is not the confidential tier, and we never label it as such; only the saxeo-confidential-* models hide the content from the host itself. The privacy ladder lays out the full progression.

Backend failover

More than one attested backend can be configured. Each is verified independently, and a confidential request routes to the first one that verifies, so a provider rotating its enclave measurement or going offline costs a failover hop instead of taking the tier down.

If no backend verifies, the request still fails closed. Failover never becomes a plaintext downgrade.

GET /v1/status reports verified_backends out of total_backends, so a partial outage (serving on the fallback) reads differently from a full one.