Verification is not a badge.
A real quote proves a measured environment, not bug-free code, absent logging, or complete GPU coverage. Approved measurements and keys bound to the actual connection matter.
Private inference / competitive intelligence
The private inference
landscape.
Same API shape. Very different trust boundaries. A feature-by-feature map of the providers, routers, and alternatives—and how TeeRouter compares once its full implementation is complete.
Future-state comparison: TeeRouter is shown as if its full implementation were complete; competitors remain documented as of 10 October 2026. The checkmarks describe that completed scenario—not current TeeRouter availability or a prediction of future competitor features.
01 / Feature matrix
Compare the whole path.
Six focused views, never more than four dimensions at once. Compare capabilities separately from limits and responsibilities; click any cell for scope and evidence.
| Product / plaintext boundary | ||||
|---|---|---|---|---|
| Plaintext: Customer gateway + model TEEDirect by default; hosted TEE optional | ||||
| Plaintext: Router TEE + upstreamPlaintext inside attested gateway | ||||
| Plaintext: Gateway TEE + model TEERouted lab models differ | ||||
| Plaintext: E2EE: chosen provider enclaveSome routes decrypt at provider gateway | ||||
| Plaintext: Local path: Tinfoil enclaveDirect path also decrypts in Nitro | ||||
| Plaintext: Enclava app + upstream TEEApp/storage coverage not established | ||||
| Plaintext: Router + provider systemsZDR is a retention control | ||||
| Plaintext: Attested router + model TEEHost operators excluded by design | ||||
| Plaintext: Client proxy ↔ model TEEPrompt keys released to verified workers | ||||
| Plaintext: Gateway TEE + model TEEExact model path must be checked | ||||
| Plaintext: Attested gateway + upstreamCustom GPU TEEs also available | ||||
| Plaintext: Selected model instance TEEEncrypted route is instance-specific | ||||
| Plaintext: Selected provider enclaveGateway or model host depends on route | ||||
| Plaintext: Client + selected compute nodeGateway/router hold ciphertext | ||||
| Plaintext: Measured inference workloadsGPU proof requires compatible verifier | ||||
| Plaintext: Provider processing systemsOrdinary inference, not preview product | ||||
| Plaintext: Customer-deployed confidential VMYour serving stack and keys matter | ||||
| Plaintext: Approved deployment / data planeProduct and workflow scopes differ | ||||
| Plaintext: Verified PCC softwareApple product; not a public model API | ||||
| Plaintext: Attested proxy / workersConversation + tool-workspace protection |
No matching entries. Try another search or category.
Completion ≠ validation.Feature support does not prove redundancy, willingness to pay, or a defensible business.Read the eight weak points →
More brands ≠ independent compute.
Routers often share upstreams. Enclava uses Privatemode and RedPill; RedPill in turn aggregates Tinfoil, NEAR, Phala, and Chutes. Separate vendors are not automatically separate failure domains.
A fallback must not weaken policy.
In the completed scenario, TeeRouter fails over only within locally approved, equally verified model-build classes—not just to another matching model name. No numerical uptime improvement is assumed here.
02 / Concept weak points
What the checkmarks don’t solve.
A complete implementation can deliver the features above and still struggle here. These are structural trade-offs and business hypotheses—not a missing-feature list or measured failure rates.
The weakest assumption: buyers will pay for independent, policy-safe redundancy that actually exists for their workload. Completing the gateway does not establish that supply, demand, or competitive advantage.
The eligible backup pool can collapse.
Strict confidentiality, EU residency, model build, tools, quotas and price constraints may leave only one—or zero—usable routes. Separate brands can share upstreams or GPU dependencies. Fail-closed verification is safe, but an expired pin or shared hardware advisory can look like an outage.
- Consequence
- The core reliability benefit can vanish for the workloads that need the strongest policy.
- Evidence needed
- Show at least two truly independent, conformance-qualified operators for the exact workload and policy, then measure failure and latency against a single-provider baseline.
Model parity is a moving target.
The same model name does not guarantee identical weights, quantization, templates, tool behavior, context limits or sampling. Published tests can approve a limited equivalence class; they cannot prove interchangeable answers for every prompt. Every relevant release may require revalidation.
- Consequence
- Coverage grows more slowly than a model directory, and adapter/parity upkeep is a continuing operating cost.
- Evidence needed
- Run representative application and tool-call suites across builds; publish the tested scope, reapproval rules and drift failures—not a universal equivalence claim.
Local control adds local responsibility.
Customers must run the gateway, secure their plaintext app boundary, manage keys and approve policy/release changes. Correct hardware quotes do not identify safe code by themselves. The verifier, update supply chain and hardware/firmware roots remain trust dependencies; conservative updates can reduce availability.
- Consequence
- More integration and support work than changing an API base URL; enterprise approval can be slow.
- Evidence needed
- Demonstrate manageable upgrades, revocation and rollback/freeze handling, clear evidence scope, and customer-approved measurement changes without accepting a server-returned verdict blindly.
Failover is not seamless answer recovery.
A fallback can rescue an eligible request before irreversible output or actions. After streaming tokens or executing a tool, switching providers can duplicate side effects, change the answer or require an application-visible retry. Backup verification, retries and hedging also add latency, quotas or cost.
- Consequence
- “Keeps inference running” must be scoped; the gateway cannot promise uninterrupted recovery of every in-flight agent run.
- Evidence needed
- Test disconnects before and after first token and tool execution; disclose failure boundaries, retry semantics, recovery latency and duplicate-call safeguards.
No traffic path means no natural tollbooth.
Direct BYOK is the privacy advantage, but customers can bypass an open-source gateway or use provider SDKs directly. Token resale is not the subscription-led core case. Paid health, policy and evidence services must earn their fee; public fleet data can be sparse, noisy or sensitive.
- Consequence
- Good architecture does not establish willingness to pay, sustainable support costs or a defensible subscription business.
- Evidence needed
- Get paid design partners who value independent reliability/evidence over the next-best alternative; measure the total operating cost of keeping their exact provider set current.
One invoice needs more than finished code.
Resale and target data classes need appropriate written provider terms; BYOK does not automatically waive those restrictions. Direct-mode credits need machine-authenticated key management, enforceable spend/rate limits and timely usage. Fraud, overshoot, supplier prepayment and account exposure remain risks.
- Consequence
- The billable catalog may be smaller than the routable catalog. Provider APIs and contracts can constrain margin, working capital and customer ownership.
- Evidence needed
- Verify written permissions and live cap/revocation/usage behavior for each billable provider, including adversarial concurrency and reconciliation—not just an adapter test.
It is not a complete private AI stack.
A router cannot make an ordinary proprietary-model API confidential, create a missing frontier-model endpoint, or protect arbitrary RAG stores, files, search and tool calls. Provider IP/account/timing metadata remains visible in direct mode. Hosted mode changes the trust boundary; it is not the same as keeping TeeRouter off-path.
- Consequence
- Some buyers need better models or packaged private workflows more than verified routing. Payload confidentiality is not anonymity or automatic compliance.
- Evidence needed
- Map the customer’s complete application data flow, model-quality needs and metadata threat model. State exactly which stages are protected and who owns the rest.
The feature checklist is not a strong moat.
TrustedRouter already documents privacy-constrained failover and BYOK; PPQ has a client-verifying encrypted path; OpenPCC has ciphertext-preserving node selection. These are not identical to independent customer-policy federation, but adjacent vendors can add adapters or client logic. A customer can build a narrow two-provider solution.
- Consequence
- The durable edge must be measured reliability, trusted release/parity upkeep and enterprise delivery—not “OpenAI-compatible + TEE.”
- Evidence needed
- Prove a workflow-level advantage buyers cannot cheaply get from existing services or a small internal integration; track whether that advantage survives competitor changes.
Paid demand + real redundancy.
Buyers pay for reliability/evidence, and at least two suitable operators remain eligible under their actual policies and terms. Benchmarks show a meaningful advantage without an unacceptable latency or quality penalty.
Verification matters; routing doesn’t.
If customers use one provider but value independent review, policy and alerts, a verifier/Trust Feed product may fit better. If billing is all they need, existing hosted routers are a strong alternative.
No paid wedge survives.
If policy leaves too few compatible suppliers, buyers won’t pay beyond token price, or comparable customer-side routing removes the advantage, a useful internal gateway may still exist without a viable standalone business.
Critical assessment derived from concept v6 §§8–11, the gateway reframe, and the cited product architectures. Several risks are shared with other TEE systems; local operations, independent-provider upkeep and direct-mode monetization are particularly relevant to this concept. No market size, margins, uptime or customer adoption is asserted.
03 / Trust boundaries
See where your prompt becomes readable.
Follow the request. Each icon above a box answers one question: how exposed are you if that party turns malicious? Click it to see who or what you rely on and why.
If this party turns malicious · click an icon for detailsSees plaintext · reads, keeps or alters everythingCode you run · a bad release you accept reads everythingTEE-bounded · operator alone can’t read contentCiphertext only · can drop, delay or observe trafficYour side · your own app and host
Your side: trusted plaintextRemote plaintext processingTEE boundary around that processingVerified encrypted channelOrdinary TLS hopCustomer-local transportTeeRouter · direct mode
Completed-implementation scenario
Your side · plaintext
Customer-local API / transport
Direct request sealed to the verified provider
TeeRouter cloud supplies control / metadata.
It is not a content hop in direct mode.
It is not a content hop in direct mode.
Readable outside your sideProvider TEE stack · no TeeRouter content hop
Standard API router
Ordinary non-TEE routes
TLS ends at each hop
Another TLS hop
Readable outside your sideRouter + provider · API / model systems
Attested gateway
TrustedRouter / RedPill · confidential paths
Verified gateway channel
Verified downstream encryption
Readable outside your sideRouter gateway TEE · + provider TEE stack
App + confidential upstream
Enclava · hosted app shown
Ordinary application API
Confidential upstream channel
Readable outside your sideApp / retrieval / stores · + upstream TEE stack
Client verification + relay
PPQ local path / AnonRouter E2EE / OpenPCC
Your side · plaintext
Customer-local API / transport
Sealed to the approved serving key
Forward sealed request
Readable outside your sideProvider TEE stack · not the ciphertext relay
Trust required is a liability. No row is trust-free. All paths assume your own app, device/OS and client integration are trustworthy. TEE paths also depend on firmware, attestation roots, verifier/supply-chain integrity and the behavior of approved code—not merely a valid quote. *Host-operator exclusion applies only to confidentiality on a fully verified, accepted path. Operators and relays can still affect availability, billing and metadata; attestation proves identity, not benign behavior.
TeeRouter · direct mode · exact scope
The customer gateway can read the prompt, verifies the approved model path, and sends directly to the provider. TeeRouter cloud is off the content path. Direct mode still reveals provider-facing IP/account/timing metadata.
Standard API router · exact scope
TLS encrypts each network hop, but terminates at the participating router/provider systems. Retention controls do not make processing operator-blind.
Attested gateway · exact scope
The customer verifies the gateway boundary; the gateway processes plaintext in its TEE and verifies/encrypts downstream. TeeRouter’s optional hosted mode follows this pattern, not the direct pattern.
App + confidential upstream · exact scope
Confidential upstream inference is not proof of operator-blind protection for the whole application or storage layer. Customer self-hosting moves that application into a different, customer-controlled trust boundary.
Client verification + relay · exact scope
A customer-side client verifies/seals; the relay forwards ciphertext without content decryption. Exact provider, protocol, model and hardware-verification scope differs between these products—this is not one uniform assurance tier.
Trust explanations · accessible reference
Your app and endpoint
Your side. A compromised app, device or host exposes every prompt and response, whichever route you pick. This risk is yours in every pattern.
- Your app, integration and device/host OS
- Your cryptographic libraries and local configuration
Your app handles readable prompts and responses. Confidential inference cannot protect them from a compromised application or local host.
This customer-side trust exists in every pattern. Self-hosting changes ownership, not the need to secure that host.
Local TeeRouter gateway / verifier
Code you run. A malicious gateway release reads every prompt before sealing and can send it anywhere. It only runs if you accept it, so pin and review releases.
- TeeRouter gateway/verifier code and its build/update supply chain
- Your measurement allowlist, policy and key handling
This process reads the prompt before sealing it. A malicious accepted update, wrong key binding or permissive verifier can send content to the wrong workload.
Direct mode removes TeeRouter SaaS from the content path—not trust in the gateway software you run. Review/pin releases and deliberately approve accepted builds.
Provider TEE hardware and serving code
TEE-bounded. Its host operator alone cannot read content on a fully verified path; it can still deny service and see metadata. Reading content would need a broken TEE (for example a physical attack on the server), a bad attestation root or malicious approved code.
- CPU/GPU vendors, firmware and attestation trust roots for this route
- Verifier logic and reviewed serving code/model builds
Hardware isolation substitutes hardware/software trust for blind host-operator trust. Attestation identifies a workload; it does not prove benign code or correct policy.
Host operators are excluded for content secrecy only on a fully verified, accepted end-to-end path. They can still affect availability, billing and account/network metadata.
Your app and endpoint
Your side. A compromised app, device or host exposes every prompt and response, whichever route you pick. This risk is yours in every pattern.
- Your app, integration and device/host OS
- Your cryptographic libraries and local configuration
Your app handles readable prompts and responses. Confidential inference cannot protect them from a compromised application or local host.
This customer-side trust exists in every pattern. Self-hosting changes ownership, not the need to secure that host.
Router operator
Sees plaintext. Reads, keeps or alters every prompt and response it routes. You have no technical way to notice; only its policies and contracts stand in the way.
- Router operator and its service/hosting stack
- Applicable access, logging and retention controls
This ordinary endpoint terminates its encrypted network connection and processes readable content. TLS protects transit, not content from the endpoint operator.
ZDR/no-training promises address handling and retention, not cryptographic inability to read content during processing.
Inference-provider operator
Sees plaintext. Reads, keeps or alters every prompt and response it serves. You have no technical way to notice; only its policies and contracts stand in the way.
- Inference-provider operator and its service/hosting stack
- Applicable access, logging and retention controls
This ordinary endpoint terminates its encrypted network connection and processes readable content. TLS protects transit, not content from the endpoint operator.
ZDR/no-training promises address handling and retention, not cryptographic inability to read content during processing.
Model-service operator
Sees plaintext. Reads, keeps or alters every prompt and response it processes. You have no technical way to notice; only its policies and contracts stand in the way.
- Model-service operator and its service/hosting stack
- Applicable access, logging and retention controls
This ordinary endpoint terminates its encrypted network connection and processes readable content. TLS protects transit, not content from the endpoint operator.
ZDR/no-training promises address handling and retention, not cryptographic inability to read content during processing.
Your app and endpoint
Your side. A compromised app, device or host exposes every prompt and response, whichever route you pick. This risk is yours in every pattern.
- Your app, integration and device/host OS
- Your cryptographic libraries and local configuration
Your app handles readable prompts and responses. Confidential inference cannot protect them from a compromised application or local host.
This customer-side trust exists in every pattern. Self-hosting changes ownership, not the need to secure that host.
Hosted gateway code and policy
TEE-bounded. Its host operator alone cannot read content inside the TEE. Malicious or lax gateway code or policy could still forward plaintext to an unverified provider, so you depend on its attested code and downstream checks.
- Gateway implementation, verification logic and routing policy
- Its downstream provider selection/checks and relevant hardware roots
The gateway decrypts inside its TEE and decides which provider path is acceptable. You rely on its software and policy for downstream verification.
An approved TEE does not remove software/policy trust. TeeRouter hosted mode follows this pattern; direct mode has a different content boundary.
Provider TEE hardware and serving code
TEE-bounded. Its host operator alone cannot read content on a fully verified path; it can still deny service and see metadata. Reading content would need a broken TEE (for example a physical attack on the server), a bad attestation root or malicious approved code.
- CPU/GPU vendors, firmware and attestation trust roots for this route
- Verifier logic and reviewed serving code/model builds
Hardware isolation substitutes hardware/software trust for blind host-operator trust. Attestation identifies a workload; it does not prove benign code or correct policy.
Host operators are excluded for content secrecy only on a fully verified, accepted end-to-end path. They can still affect availability, billing and account/network metadata.
Your app and endpoint
Your side. A compromised app, device or host exposes every prompt and response, whichever route you pick. This risk is yours in every pattern.
- Your app, integration and device/host OS
- Your cryptographic libraries and local configuration
Your app handles readable prompts and responses. Confidential inference cannot protect them from a compromised application or local host.
This customer-side trust exists in every pattern. Self-hosting changes ownership, not the need to secure that host.
Hosted application, retrieval and stores
Sees plaintext. Reads application memory, retrieval context, files, logs and stored data. The confidential upstream does not protect any of that.
- Hosted app/RAG operator and application code
- Storage and integration operators for this workload
Confidential upstream inference does not itself protect application memory, retrieval context, files, logs or storage. Whole-app operator-blind protection is not established for the assessed hosted path.
Self-hosting changes the application boundary but still requires secure software and hosts. This is an evidence/scope distinction, not proof of a breach.
Provider TEE hardware and serving code
TEE-bounded. Its host operator alone cannot read content on a fully verified path; it can still deny service and see metadata. Reading content would need a broken TEE (for example a physical attack on the server), a bad attestation root or malicious approved code.
- CPU/GPU vendors, firmware and attestation trust roots for this route
- Verifier logic and reviewed serving code/model builds
Hardware isolation substitutes hardware/software trust for blind host-operator trust. Attestation identifies a workload; it does not prove benign code or correct policy.
Host operators are excluded for content secrecy only on a fully verified, accepted end-to-end path. They can still affect availability, billing and account/network metadata.
Your app and endpoint
Your side. A compromised app, device or host exposes every prompt and response, whichever route you pick. This risk is yours in every pattern.
- Your app, integration and device/host OS
- Your cryptographic libraries and local configuration
Your app handles readable prompts and responses. Confidential inference cannot protect them from a compromised application or local host.
This customer-side trust exists in every pattern. Self-hosting changes ownership, not the need to secure that host.
Client verifier and sealing code
Code you run. A malicious client or SDK release reads every prompt before sealing and can bind it to the wrong key. It only runs if you accept it, so pin and review releases.
- Client/SDK/verifier supplier and release supply chain
- Your acceptance policy and channel/key binding checks
The client decides which workload and key may receive content. A valid quote does not help if the client accepts unreviewed code or binds the wrong key.
Ciphertext routing does not remove client-code trust. Exact hardware-verification scope varies by product, model and protocol.
Ciphertext relay: availability / metadata only
Ciphertext only. Can drop, delay or log which account talks to which provider, when and how much. It cannot read content on this verified end-to-end path.
- Relay operation for delivery, availability and visible metadata
The relay forwards a payload sealed to the accepted serving key. It is not a decryption point and does not require operator trust for payload confidentiality on this verified E2EE path.
A relay can still drop/delay traffic or observe routing/account/network information. Ciphertext forwarding is not anonymity or an uptime guarantee.
Provider TEE hardware and serving code
TEE-bounded. Its host operator alone cannot read content on a fully verified path; it can still deny service and see metadata. Reading content would need a broken TEE (for example a physical attack on the server), a bad attestation root or malicious approved code.
- CPU/GPU vendors, firmware and attestation trust roots for this route
- Verifier logic and reviewed serving code/model builds
Hardware isolation substitutes hardware/software trust for blind host-operator trust. Attestation identifies a workload; it does not prove benign code or correct policy.
Host operators are excluded for content secrecy only on a fully verified, accepted end-to-end path. They can still affect availability, billing and account/network metadata.
Direct mode removes the TeeRouter content hop—not all trust. Customer-side verification and ciphertext-only routing already exist elsewhere. Direct mode keeps verification/routing policy with the customer; hosted TeeRouter mode instead processes plaintext in TeeRouter’s TEE. Application privacy, metadata and supplier/model eligibility remain separate questions.
Visual approach adapted from the earlier concept diagram. Competitor examples refer only to the assessed modes above; full evidence and caveats remain in the matrix. TeeRouter is shown as a completed-implementation scenario.
04 / Completed product scope
The full implementation, in view.
All four capability areas from concept v6, treated as implemented for this comparison. Runtime and commercial eligibility constraints still apply.
01DIRECT ROUTING
Verified direct routing.
- Customer-run gateway + BYOK
- Conformance-qualified independent TEE providers
- Streaming, tools, structured output
- Local policy, build parity, evidence ledger
- Health-aware, policy-safe failover
Runtime guardrail: approved provider conformance and model parity before a route can receive content.
02HOSTED + BILLING
Hosted access + billing.
- Hosted attested EU endpoint
- Signed feeds and published conformance
- Additional adapters and team controls
- Optional ciphertext relay
- Unified billing only per approved provider
Commercial scope: unified billing only on contract-approved providers with enforceable spending controls and reconciliation.
03ENTERPRISE
Enterprise policy.
- SSO / SCIM and governance
- Customer co-signed endorsements
- Policy-derived subprocessor lists
- Customer-owned confidential routes
- Verifiable frontier endpoints, if available
Contractual scope: enterprise controls do not themselves establish certification, legal compliance, or a provider agreement.
04ECOSYSTEM
SDKs + provider ecosystem.
- Embedded browser / mobile SDKs
- OHTTP and blind-token anonymity mode
- Provider integration kit
- Public conformance program
- Transparent coverage and limitations
Trust boundary: interoperability and reviewed evidence remain required; provider-name badges are not verification.
Scenario assumption: the full implementation is complete, including conformance tooling and enterprise interfaces. This page does not claim deployment today, signed supplier agreements, certification, or new confidential frontier-model availability.
Watch: frontier-model private inference
OpenAI’s announced Private Inference preview belongs on the watchlist, not in the “verified today” column. Production access and customer-verification details are not established here. Its separate Private Safety Processing protects asynchronous review, not by itself primary GPT inference.
Alternative: compute on ciphertext
Zama’s FHE tooling is a genuinely different approach. Hybrid client/server LLMs and performance constraints make it a workload-specific alternative, not a drop-in replacement for these TEE APIs.
05 / Evidence & methodology
Sources, not scores.
A dated public-documentation snapshot. Open each entry for primary links and its comparison scope.
How to interpret the matrix
- Documented: described in the named product’s official docs or source.
- Scoped: model, deployment, protocol, tier, or verification-policy restrictions apply.
- Not established: insufficient evidence; not proof the feature is absent.
- Outside scope: not a comparable offering in that dimension.
- Completed scenario: TeeRouter support after implementation, not current availability. ✓*: commercial/provider eligibility still applies.
What this page does not establish
We did not use private credentials, invoke live models, validate deployed quotes, benchmark latency, or audit provider software. Published no-retention policies, client verification, reviewed software identity, and protected CPU–GPU links are separate properties.
There is no composite “privacy score.” Hardware assumptions, metadata visibility, legal agreements, logging boundaries, and model-build differences matter. A TEE is not a compliance certificate.
01TeeRouter
Design sources for the completed-implementation scenario; not current deployment evidence.
02TrustedRouter
Hosted attested router · documentation evidence, not a live verdict.
03RedPill
Attested multi-provider gateway · documentation evidence, not a live verdict.
04AnonRouter
Privacy router + E2EE SDK · documentation evidence, not a live verdict.
05PPQ / PayPerQ
Aggregator + local verifier · documentation evidence, not a live verdict.
06Enclava
Application platform + router · documentation evidence, not a live verdict.
07OpenRouter
General model aggregator · documentation evidence, not a live verdict.
08Tinfoil
Verified inference + containers · documentation evidence, not a live verdict.
09Privatemode
EU confidential inference · documentation evidence, not a live verdict.
10NEAR AI Cloud
TEE model fleet + gateway · documentation evidence, not a live verdict.
11Phala
GPU TEE cloud + inference API · documentation evidence, not a live verdict.
12Chutes
Inference platform + TEE pool · documentation evidence, not a live verdict.
13Venice
Consumer AI + model API · documentation evidence, not a live verdict.
14Confident Security
CONFSEC / OpenPCC stack · documentation evidence, not a live verdict.
15Confidential.ai
Inference + CVMs + licensed stack · documentation evidence, not a live verdict.
16Enterprise lab APIs
OpenAI / Anthropic / Bedrock · documentation evidence, not a live verdict.
17Azure / Google GPUs
Build-your-own confidential infrastructure · documentation evidence, not a live verdict.
18Enterprise CC platforms
Opaque / Fortanix / Anjuna · documentation evidence, not a live verdict.
19Apple PCC
Apple Intelligence infrastructure · documentation evidence, not a live verdict.
20Confer
End-to-end private assistant · documentation evidence, not a live verdict.