The privacy ladder

"Private" hides two different things, and it pays to keep them apart: who is asking, and what is being asked. Saxeo's catalog climbs a ladder of three rungs, and each rung is labeled with what it actually guarantees, never more.

Rung 1: Anonymized (live)

Every request already leaves the gateway on Saxeo's own upstream account. The vendor serving the model sees Saxeo'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 Saxeo and the vendor, so no single party sees both halves: the request travels caller → Saxeo → intermediary → vendor. Saxeo 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 Saxeo's (or the intermediary's) identity, never a caller's. No single party outside Saxeo 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, saxeo-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, saxeo-confidential-qwen3.6-35b and saxeo-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 saxeo (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/models for the sable-private ids 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 Saxeo 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.