> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Trust tiers

Z supports four trust tiers. Each tier represents a distinct cryptographic and operational guarantee about how a request is handled. Tier selection is per request. The gateway enforces the boundary; it does not silently downgrade or fall back across tiers.

This is the headline architectural property of the gateway. A developer can use Z for ordinary frontier-model inference at Tier 1 and for sensitive workloads under hardware attestation at Tier 3 from the same client, by changing one parameter per call.

## The four tiers

### Tier 1 — Pass-through

Model suffix: `:anon` (default)

Tier 1 routes to frontier providers on standard cloud infrastructure. The gateway is an anonymizing proxy: Z does not retain prompts or completions, but the upstream provider operates under its own retention and content policies. Tier 1 is the right choice for general-purpose work where the privacy guarantee that matters is that Z itself does not retain the content, and where the developer trusts the upstream provider's own posture for the rest.

Egress moderation on Tier 1 defers to the upstream provider's native guardrails. The gateway propagates the provider's flags as response headers but does not impose its own content filter.

### Tier 2 — Private

Model suffix: `:private`

Tier 2 routes to partner GPU networks running open-source models under contractual privacy commitments. The upstream operator agrees, by contract, not to retain or train on the content. This is a contractual guarantee, not a cryptographic one: the gateway cannot prove the partner is honoring the agreement, only that the agreement exists.

Tier 2 is appropriate for workloads where the model choice is open-source-compatible and where the regulatory or commercial posture benefits from explicit contractual coverage in addition to Z's own Zero Data Retention.

CSAM scanning on Tiers 2 and 3 is performed by the gateway via a perceptual hash check at ingress. The scan operates on the prompt in memory only and is not logged or retained beyond its verdict. The scanner is fail-closed: when the scanner is unavailable, the request returns `503 content_safety_unavailable` rather than being passed through unscanned.

### Tier 3 — Managed Verifiable Hardware

Model suffix: `:tee`

Tier 3 routes to nodes running inside hardware-attested trusted execution environments. Attestation verification must complete before any payload is dispatched to the node. This ordering is mandatory and not performance-optional: a node that has not produced a valid attestation cannot receive a request.

The attestation chain proves three things: that the code running inside the enclave is the code Z approved for that model and tier; that the hardware is genuine, signed by the hardware vendor's root of trust; and that the attestation has not been revoked.

Tier 3 is the right choice for workloads where the integrity of execution matters and the developer needs hardware-level evidence that the request ran inside an attested enclave. Video is not supported on Tier 3. Z observes plaintext on Tier 3 and there is no in-line video content-safety scanner at V1. Video workloads requiring privacy use Tier 4.

### Tier 4 — Sovereign End-to-End Encrypted

Model suffix: `:e2ee`

Tier 4 is end-to-end encrypted between the client and the TEE node. The client and node perform an ephemeral X25519 ECDH key exchange via `/v1/handshake`. The prompt is encrypted to the resulting session key under AES-256-GCM with a fresh random nonce per request. The gateway sees ciphertext only; it is a blind byte-pipe and holds no decryption key.

The trade-off Tier 4 makes is that the gateway cannot inspect content for moderation, web search injection, persistent memory features, or gateway-resolved tool calls. Compliance for Tier 4 is anchored to a per-session signed AUP attestation rather than to content inspection. A Tier 4 session cannot begin until the wallet has signed the current AUP version.

Tier 4 is the only tier where Z is cryptographically incapable of seeing user content. Anywhere "Z does not see your data" is the load-bearing claim, Tier 4 is the correct answer.

Tier 4 is wallet-native. Subscription-tier users access Tier 4 by linking a wallet to their account.

## How tier selection works

Tier is selected on a per-request basis by appending a suffix to the model identifier in the request body:

```json theme={null}
{
  "model": "deepseek-v3:tee",
  "messages": [...]
}
```

For SDKs that do not permit model-string mutation (some agent frameworks pin model strings to a fixed enumeration), tier is also selectable via header:

```text theme={null}
X-Z-Tier: tee
```

The two forms are equivalent. If both are present and disagree, the request is rejected with `400 tier_conflict`.

If no suffix or header is provided, the request defaults to `:anon`. In the TypeScript SDK, `tier: 'auto'` resolves to Tier 1; there is no automatic tier escalation. Explicit opt-in is required for Tiers 2, 3, or 4 to prevent silent changes to billing behavior or privacy guarantees.

## What "cryptographically enforced" means

Tier enforcement happens at parse and at routing. The gateway extracts the tier specifier before any other processing. The request is then routed to a pool of nodes that are eligible for that tier and only that tier. Cross-tier fallback is disabled: if no healthy node is available at the requested tier, the request fails with a `5xx tier_unavailable` rather than degrading to a lower tier.

For Tiers 3 and 4 there is an additional cryptographic gate. Billing finalizes only after the gateway verifies a fresh hardware attestation from the serving node. A node whose attestation fails or whose code measurement is not on the active allowlist cannot produce a billable response, regardless of what the routing layer attempts.

The practical implication: a developer who selects Tier 3 for a sensitive workload can rely on Tier 3 properties holding for that call, or on the call failing. The gateway will not deliver a Tier 1 response in response to a Tier 3 request.

## Selecting a tier

The right tier is the lowest tier that meets the workload's actual trust requirement. Tiers are not strictly ordered in cost or latency. Tier 1 frontier models are often the most expensive, but they are ordered in operational constraint. Tier 4 has the strongest cryptographic guarantee and the most integration surface to manage.

Rules of thumb:

* Default tooling, internal experimentation: Tier 1.
* Production workloads where the regulatory posture wants contractual privacy coverage: Tier 2.
* Workloads where the developer needs to attest to a counterparty that execution is integrity-protected: Tier 3.
* Workloads where the gateway must not be able to see the content under any circumstance: Tier 4.

Tier 4 is the only tier that holds up against a fully adversarial threat model on Z itself. The other tiers trust Z's operational posture for the parts of the system the cryptography does not cover.