The privacy ladder
"Private" hides two different things, and it pays to keep them apart: who is asking, and what is being asked. Sable's catalog climbs a ladder of three rungs, and each rung is labeled with what it actually guarantees, never more.
| Rung | Hides | From whom | Status |
|---|---|---|---|
| Anonymized | HidesWho is asking | From whomThe model vendor | StatusLive: every request, today |
| Double-blind | HidesWho and what, from any single party | From whomVendor and intermediary, respectively | StatusLive: the sable-private lane; active where /v1/models lists it |
| Confidential | HidesWhat is asked | From whomThe serving host itself | StatusLive for the two sable-confidential-* models |
Rung 1: Anonymized (live)
Every request already leaves the gateway on Sable's own upstream account. The vendor serving the model sees Sable's identity, never yours: not your identity, not your API key, not your payment details. There is no per-caller vendor account, so there is nothing on the vendor's side to tie a prompt to you.
What this rung does not hide: the content. The vendor's infrastructure processes the plaintext prompt: that is what running the model means. So anonymized access is not "private from the vendor's servers", and we don't call it confidential. It hides who, not what.
This is the baseline for the whole catalog, including the frontier slate of closed vendor models.
One control sits orthogonal to the rungs: opt-in
outbound scrubbing (sable_scrub: true) redacts secret
shapes (emails, API keys, EVM addresses, long hex) from the outbound prompt
before it leaves the egress frame. It narrows what reaches the vendor
without changing which rung you're on: pattern-based redaction, not
anonymization of the content.
Rung 2: Double-blind (the sable-private lane)
A pinned second intermediary (Venice) sits between Sable and the vendor, so no single party sees both halves: the request travels caller → Sable → intermediary → vendor. Sable knows who asked but the content only transits its egress frame and is never persisted; the intermediary and vendor process the content but only ever see Sable's (or the intermediary's) identity, never a caller's. No single party outside Sable holds who and what together.
The guarantee rests on provider pinning: these models are bound to exactly one upstream and never fail over: when the route is down the request fails, it is not quietly served through a path with a different privacy posture. The intermediary's default system prompt is disabled at the egress shim, so nothing you didn't send shapes the reply or your bill.
The lane's models (sable-private, sable-private-fast,
sable-venice-uncensored) are listed in the
catalog. A deployment
without the pinned route configured omits them from GET /v1/models; if you
can see them there, the rung is active on that deployment.
What this rung does not hide: the vendor's infrastructure still processes the plaintext to run the model. Double-blind separates who from what; it does not make the computation confidential: that is rung 3.
Rung 3: Confidential (live for two models)
The top rung hides the content from the host running the model:
hardware-attested Intel TDX. The gateway cryptographically verifies the
enclave's TDX quote against a pinned measurement before routing, and that
result lands in your signed receipt as an attestation
block (verification: "tee-attested"). The host provably cannot read the
prompt, and you can check the proof yourself rather than take our word.
The per-response half is not there yet: response_bound reads false on every
receipt this deployment issues, because binding a specific answer to the
enclave requires re-hashing the raw response bytes and the chat handlers do not
yet hand them to the check. What that leaves
open.
The pin is on MRTD, the enclave's base image, not on the workload build — what that covers. It proves a genuine TDX enclave running the expected base image; it does not pin which build of the model server is inside it.
This is live for exactly two models, sable-confidential-qwen3.6-35b and
sable-confidential-gemma4-26b, and they are the only models allowed to
carry the word "confidential". A confidential-tier request
for any other model fails closed with 400, never a silent downgrade to a
plaintext host.
The flagship lane reaches this rung through its
privacy dial: calling sable (or
sable-fast / sable-max) with sable_privacy_tier: "confidential" routes
to these attested models instead of being refused: the receipt keeps the
requested id and records the engine plus the attestation.
Reading the ladder honestly
- Rung 1 is a real property of every live request, and it is the weakest of the three. Don't mistake it for rung 3.
- Rung 2 separates identity from content across parties: it is a routing
property, not a hardware guarantee. Check
/v1/modelsfor thesable-privateids to confirm it is active on the deployment you call. - Rung 3 is the only rung with a hardware guarantee, and it applies to two models. Everything else on the catalog runs on a host that sees the prompt. The privacy contract governs what Sable itself stores (metadata only, never content) regardless of rung.
See also: Privacy tiers for how requests select the attested path, Models for which ids sit on which rung, and Verifiable receipts for the proof that rides with every response.