Architecture deep dive

TEE-Terminated TLS vs E2EE

Both designs can keep an AI prompt encrypted until it reaches an attested workload. They use different keys, place different demands on the client, and fail in different ways.

Written for readers without a confidential-computing background

Direct answer

What is the difference between TEE-Terminated TLS and E2EE?

TEE-terminated TLS puts the ordinary HTTPS private key inside the attested TEE. The client uses HTTPS normally, while a load balancer can forward encrypted bytes without reading them. Application E2EE encrypts the AI payload to a separate key that is bound to the attested TEE. The outer HTTPS connection may end at an API gateway, but that gateway still cannot decrypt the protected payload.

Both can provide a strong client-to-TEE content boundary. A TEE-only gateway does not: it decrypts HTTPS before forwarding the request to a TEE, so the gateway can read the prompt.

TEEThe protected room where code and data are processed.
AttestationThe signed inspection report describing that room.
Encrypted channelThe locked delivery path into the room.

Three request paths

Where the prompt first becomes plaintext

HTTPS and TEE badges do not answer this by themselves. Find the first component that holds a decryption key, then check whether that key is cryptographically bound to fresh attestation.

A

Direct attested channel

TEE-Terminated TLS

Your app opens a normal HTTPS connection, but the TLS private key is held inside the attested TEE. Network devices and load balancers may forward the encrypted connection; they must not terminate it.

A verifier checks a cryptographic binding between the hardware report and the key used by the live TLS endpoint. A normal browser padlock proves the domain identity, not that the corresponding private key lives inside a TEE.

Your app Prompt encrypted by TLS
Network / load balancer Forwards ciphertext and sees metadata
Attested TEE TLS key, first plaintext, model execution
Gateway access
Cannot read the prompt when TLS is passed through
Client change
Usually standard HTTPS plus attestation verification
Critical proof
The live TLS endpoint key is bound to a fresh valid quote
B

Payload protected through the gateway

Attested Application E2EE

Your app first verifies a public encryption key from the attested TEE. It encrypts the prompt to that key before sending the request through the ordinary HTTPS API.

The gateway may terminate outer TLS, authenticate the account, bill the request, and route it. It sees ciphertext instead of the protected prompt. If the client accepts an unverified key from that gateway, the gateway can substitute its own key and the E2EE claim fails.

Your app Verifies attestation, encrypts payload
HTTPS API gateway TLS ends; E2EE payload remains encrypted
Attested TEE E2EE key, first plaintext, model execution
Gateway access
Sees routing metadata and ciphertext, not protected content
Client change
Requires an SDK or application encryption protocol
Critical proof
The E2EE key, freshness, request, and response bind correctly
C

Backend protection only

TEE-only Gateway

Your HTTPS connection ends at a conventional API gateway. The gateway decrypts the request and sends it to a TEE backend, often over another protected connection.

The gateway can read the prompt. The TEE may protect model execution from the backend host or cloud administrator, but it does not protect prompts from the API operator, gateway logs, or a compromised gateway.

Your app Prompt encrypted by TLS
HTTPS API gateway TLS key and first plaintext
TEE backend Receives prompt for model execution
Gateway access
Can read and potentially log the prompt and response
Client change
Works with ordinary HTTPS clients
Critical limitation
No cryptographic client-to-TEE content boundary

Side-by-side

TEE TLS vs E2EE: pros and cons

E2EE is not automatically better. The useful question is which operators the design excludes and whether its key binding is actually verified.

Question TEE-Terminated TLS Attested Application E2EE TEE-only Gateway
First plaintextInside the attested TEEInside the attested TEEAt the API gateway
Gateway sees contentNo, when it only passes TLS throughNo, for fields inside the E2EE envelopeYes
Client integrationStandard HTTPS plus attestation checksEncryption SDK or protocol integrationStandard HTTPS
Attested keyTLS endpoint keyApplication encryption keyUsually only a backend identity
Operational strengthStreaming and API compatibilityWorks through TLS-terminating gateways and CDNsSimple routing and compatibility
Main tradeoffTEE must manage TLS identity and direct connectionsMore client, key, retry, and streaming complexityGateway remains trusted with plaintext
Route proofStrong when the live TLS peer key is attestedStrong when requests and responses bind to the attested keyA separate backend quote is not enough

Threat model

Who can still see or influence a request?

A threat model names the systems and operators you do not want to trust. No single badge covers every threat.

Network observer

Protected by all three designs. TLS hides content while it crosses the public network. IP addresses, endpoints, and traffic patterns can remain observable.

Cloud or host administrator

TEE protection is intended for this threat. A policy-approved quote can show isolation from the host, subject to hardware, firmware, and side-channel limitations.

Gateway or CDN operator

Protected only when the content key stays beyond the gateway. TEE-TLS requires passthrough. Application E2EE keeps the payload encrypted when outer TLS ends there.

Malicious code inside the TEE

Not solved by encryption or isolation. Code that legitimately receives plaintext can log or export it. Measurements and source provenance identify code; review and policy determine whether it is acceptable.

Reseller or compromised control plane

A backend quote alone is insufficient. Evidence must connect the request to the claimed model and backend, or a valid enclave can exist while traffic takes another route.

Metadata observer

Traffic size and timing normally remain visible. Account identity, billing, IP address, model route, and unencrypted headers may also be exposed.

The reseller problem

Infrastructure evidence is not request evidence

The API provider owns the endpoint and customer relationship. The infrastructure provider operates the TEE, GPU, or confidential platform. An aggregator can use several infrastructure providers under one brand.

A strong request-bound route connects a fresh client challenge, requested model, backend identity, and response to the same attested key. Without that connection, attestation proves that a suitable backend exists, not that it served this request.

Choosing a design

Start with the operator you need to exclude

I need standard API compatibility

Prefer TEE-terminated TLS when the service proves the live TLS key is inside the TEE. It usually preserves normal clients, streaming, retries, and tool calls.

I must use an external gateway or CDN

Prefer attested application E2EE when an intermediary must route requests but must not read prompts. Confirm both request and response protection.

I only need backend host isolation

TEE-only may be sufficient when you explicitly trust the API operator and gateway with plaintext. It should not be described as protection from that operator.

For either strong channel design, verify:

  • A fresh hardware quote validates against the vendor trust chain.
  • The decryption key is cryptographically bound to that quote.
  • The measured workload matches a reviewed policy and known source or build.
  • The requested model and actual route bind to the response where possible.
  • Failures stop the request instead of silently using an unverified path.

Use the guide

Definitions explain the claim. The directory shows what is currently evidenced for each provider and model route.

Primary references

Standards behind the architecture

The standards define protocol behavior and attestation roles. They do not validate any provider-specific implementation.