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="sable-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: sable, 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 sable-confidential-qwen3.6-35b and sable-confidential-gemma4-26b. Those models run inside an attested Intel TDX enclave (with NVIDIA H100 confidential computing) on an attested backend. Before routing, the gateway cryptographically verifies the enclave's TDX quote against a pinned measurement; after the response, it verifies a per-response signature from the key bound into that quote. Both results are stamped into your signed receipt as an attestation block (verification: "tee-attested", response_bound: true), so you can confirm, yourself, that your request ran in 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.

One operational consequence of that fail-closed rule, stated plainly: when the enclave workload is redeployed upstream, its attested measurement 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 Sable 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 Sable'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 sable-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.