TEE
Trusted execution environment
A hardware-isolated execution environment that protects data in use from the host under its platform assumptions. A TEE alone does not establish user-verifiable attestation.
PRIVACY, WITH A PROOF OBLIGATION
Private AI inference
you can verify.
Compare the mechanisms that keep inference data private.
See where plaintext exists, who you still trust, and what you can independently verify.
Privacy policies alone do not qualify a provider for inclusion.
THE PRIVACY SPECTRUM
Read the methodology Different mechanisms. Different trust.
Attestation-bound keys
A client or key broker releases secrets only to a successfully verified, expected workload. The encryption boundary must terminate inside protected execution, not at a provider TLS gateway.
Trust the platform, workload, and key-binding design.An assurance and trust spectrum, not a universal security ranking. FHE, MPC, and TEEs solve different threat models.
THE DIRECTORY VERSION 2
Research methodology Compare the full privacy boundary.
Request protection, private computation, retention, and metadata. Follow the evidence across every layer.
Model hosts and compute networks, reviewed 2026-10-06. Aggregator routes are excluded; mixed services are assessed only for their documented own hosting. Ratings apply to the stated deployment path; TEE support is not a platform-wide guarantee.
11 of 11 providers · Content stage, descending
PhalaIntel TDX · NVIDIA · app configuration | |||||||
NEAR AIIntel TDX · NVIDIA · verified gateway | |||||||
TinfoilCPU TEE · NVIDIA · reproducible images | |||||||
PrivatemodeAMD / Intel · NVIDIA · Contrast | |||||||
CocoonIntel TDX · NVIDIA · TON registry | |||||||
Secret AIIntel / AMD · NVIDIA · worker verification | |||||||
PrivasysIntel TDX · NVIDIA · pinned fleet configuration | |||||||
ConferIntel / AMD · NVIDIA · signed releases | |||||||
Super ProtocolIntel / AMD · NVIDIA · Swarm root CA | |||||||
ChutesIntel TDX · NVIDIA · optional E2EE | |||||||
VeniceVenice policy · hosting claim |
Every provider has a numbered stage. Stage 0: privacy claimed. Stage 1: partial proof. Stage 2: all content layers proven. Stage 3: independently auditable. Click a stage for its requirements and progress; identity and metadata are assessed separately.
THE QUESTION THAT MATTERSWhy should you believe the operator
Read our methodology Why should you believe the operator
cannot see your data?
Look for the boundary, the verification procedure, and the assumptions.
A privacy promise is the beginning of a question, not the answer.
A SHORT FIELD GUIDE
Understand the mechanisms.
The terms behind the guarantees.
Remote attestation
Verify before sending secrets
A client checks signed evidence about a protected environment before sending secrets. Coverage depends on what the report actually measures.
Attestation measurement
The identity of measured code
A cryptographic digest of measured software or configuration. A boot measurement is not automatically the identity of the application, container, or model.
Attestation-bound keys
Release only to an approved workload
Keys or session secrets become available only after verification of the expected environment and workload. Freshness and binding the session key to that report matter.
FHE
Fully homomorphic encryption
Computation over encrypted values without server-side input decryption. The protected scope, output encryption, client processing, and scheme assumptions still matter.
MPC
Secure multi-party computation
Participants jointly compute on private inputs, often represented as secret shares. Privacy depends on the protocol's corruption and non-collusion assumptions.
Plaintext boundary
Where unencrypted data can exist
The components that can hold readable input, intermediate values, or output. Ordinary HTTPS may end at a provider gateway, outside a protected workload.
Trust assumption
What the guarantee still relies on
A party, implementation, hardware property, or cryptographic assumption that must hold for the confidentiality claim to be valid.