A claim is a starting point.
Evidence is the standard.

What qualifies for inclusion?

To establish technical privacy, a provider must use a mechanism intended to prevent a provider or infrastructure operator from accessing sensitive plaintext during inference: a protected execution environment, an attested encrypted channel, or a cryptographic private-computation construction. We identify exactly which operator is excluded, what data is protected, and which assumptions remain.

Providers must run the models themselves or supply the software and compute network where operators run them. API aggregators such as OpenRouter are excluded. For services with both hosting and aggregation, only the documented hosting tier qualifies, and unresolved per-model hosting stays explicit. Version 2 also compares hosts with policy-based privacy, such as Venice's own Private tier, at Stage 0. No logging, no retention, no training, dedicated compute, compliance certifications, privacy policies, and contractual promises alone do not establish technical privacy.

The five questions we ask

1. What is protected? Inputs, outputs, intermediate values, and the explicitly documented scope.
2. Who is prevented from seeing it? The host, provider administrators, individual MPC participants, or another precisely named party.
3. What enforces that protection? Hardware isolation, verified workload identity, key binding, ciphertext computation, or secret sharing.
4. Who and what must still be trusted? Hardware vendors, provider code, a verifier, a key broker, or cryptographic and non-collusion assumptions.
5. How can the user verify it? Retrievable reports, expected measurements, public tooling, protocols, and reproducible evidence.

Version 2 content privacy stages

Every inference provider has a numbered stage from 0 to 3. A stage applies to the stated model tier, client, configuration and deployment path. It assesses inputs and outputs across the request path, computation, and content logs and storage. Identity and operational metadata remain visible as a separate assessment.

What Stage 1 requires

At least one of the three content layers below must have independently checkable technical evidence. This is partial proof: an attested inference worker can earn Stage 1 while its request path or retention remains unresolved. Policy promises and TEE marketing alone stay at Stage 0. If no technical proof is established, the provider still has Stage 0 and its factor assessments explain the evidence gaps.

Partial technical proof within one layer also earns Stage 1. For example, checkable VM isolation with unresolved GPU protection is partial execution evidence. It does not mark the complete execution requirement as met or qualify for Stage 2.

What Stage 2 requires

All three steps must be proven for full content privacy across the assessed path. Stronger evidence in one step cannot compensate for a missing step.

1. Private inputs and outputs in transit. E2EE or an equivalent channel bound to the expected protected workload must prevent an intermediary from reading content. Verification happens before secrets are sent and fails closed. Ordinary HTTPS to a plaintext gateway is insufficient.
2. Protected computation. Technical evidence must identify the approved workload and cover every component that processes plaintext, including CPU and GPU workers where applicable. Key custody, model identity and hardware or cryptographic assumptions must be explicit.
3. Enforced content handling. Inputs and outputs must not be logged, persistently stored, used for training or exposed through traces, files or backups. Protected temporary caches are allowed when isolation and removal are verifiable against the accepted implementation and configuration. Content-derived cache state counts as sensitive content.

Remote attestation identifies running code and configuration. To establish cache removal, the accepted code must enforce its documented lifetime or clear operation. Memory-pressure eviction, a possible future restart, or rotating a cache salt does not by itself establish when old entries are removed. We do not infer deletion from a TEE badge or read-only disks.

Steps within each stage

Each provider's stage tooltip shows its current stage, the next stage's requirements, and the evidence status of each step. Stage 1 needs proof for any one content layer; Stage 2 needs all three. Stage 3 additionally requires independently auditable implementations across all three. Missing evidence is not proof of failure, but it cannot satisfy a step.

Metadata is assessed separately

Accounts, IP addresses, API keys, token totals and billing records do not automatically lower the content stage. Their collection, linkage and retention remain explicit in the metadata column. Telemetry containing prompts, responses or content-derived state is still assessed as content retention; calling it metadata does not exempt it.

Stage 3 requires independent inspection of all three content factors, their deployed-artifact linkage and update controls. Public source alone is insufficient. Verifiable and auditable describe available capabilities under stated assumptions; this index has not completed a live attestation or security audit.

How to read verification labels

These legacy labels describe verification capabilities. Version 2 separately assesses request protection, inference execution, logs and storage, and identity and metadata. A source-review date records research, not successful verification of every live deployment.

Assurance describes the approach

These approaches are not an absolute security ranking. FHE, MPC, and TEEs have different protected scopes, threat models, implementation risks, and trust assumptions. We do not collapse those differences into a score.

Evidence standards

We prioritize inspectable enforcement over an unsupported assertion. The list below describes progressively weaker direct support for an implementation claim; a cryptographic protocol and a hardware report answer different questions and are not substitutes for one another.

1. User-retrievable attestation evidenceSigned reports a customer can obtain, with freshness checks and a clear hardware endorsement chain.
2. Public attestation verification procedureInstructions identifying exactly what is checked, by whom, and before which secrets are sent.
3. Attestation-bound key release designEvidence that a session key or decryption secret is released only to the intended, verified workload.
4. Open-source verifierInspectable verification code, expected-measurement handling, failure behavior, and session-key binding.
5. Open workload or reproducible measurementA connection between reviewed source, the deployed workload, and the measurement a customer checks.
6. Published cryptographic constructionA protocol, threat model, protected computation scope, and explicit security assumptions for FHE or MPC.
7. Independent security analysisA scoped analysis tied to the relevant implementation and version; audits do not replace checking deployment identity.
8. Detailed architecture documentationA traceable plaintext boundary, key lifecycle, and account of all trusted components.
9. Vendor technical claimUseful as a lead for investigation. A claim alone does not establish customer-verifiable enforcement.

Each source states which fields it supports. Vendor claims are labeled separately. A link to documentation is evidence of a documented design, not proof that every deployed instance implements it.

Unknown means unknown

We do not infer attestation from TEE support, workload identity from a boot measurement, key isolation from encryption, or end-to-end private inference from ordinary HTTPS. If a source does not establish an answer, we display “Unknown.”

“Not applicable” is reserved for a property absent from the architecture, such as hardware attestation for a pure FHE circuit. False and unknown values never satisfy affirmative verification filters.

Trace the entire plaintext boundary

Ordinary TLS protects data while it travels to a TLS endpoint. If that endpoint is a provider gateway, plaintext may exist there before inference. An attested encrypted inference channel instead binds the destination key to a verified protected workload and decrypts only inside that boundary.

For FHE, we ask which operations use encrypted values and whether results return encrypted. For MPC, we ask what each participant sees, how many may be corrupted, and whether collusion breaks privacy. Hybrid designs must document the boundary at every transition.

About retained demonstration fixtures

Obscura, Aperture, Tern Compute, Cipherfield, Split Protocol, and Veil are fictional providers created for this interface. Their architecture descriptions, source documents, verification-tool claims, dates, and evidence links are demonstration fixtures. References to hardware technologies illustrate possible designs and do not describe any real provider’s deployment.

“Demo reviewed” records review of the static fixture, not verification of a live service. There are no real attestation endpoints, actual verification tools, independent audits, or published research papers in the seed data. The protocol pages are fictional specimens.

Tern Compute intentionally demonstrates missing evidence. A real directory would keep an unresolved record outside its confirmed private-provider list until the inclusion requirement is established. Aperture demonstrates a narrower host-isolation guarantee with provider-held keys, not provider blindness.