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 | Who is asking | The model vendor | Live: every request, today |
| Double-blind | Who and what, from any single party | Vendor and intermediary, respectively | Live: the sable-private lane; active where /v1/models lists it |
| Confidential | What is asked | The serving host itself | Live 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 verifies
a per-response signature from the key bound into that quote afterward. Both
results land in your signed receipt as an attestation
block (verification: "tee-attested", response_bound: true). The host
provably cannot read the prompt, and you can check the proof yourself rather
than take our word.
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.