Plain-language reference

Confidential AI Inference FAQ

Direct answers about trusted execution environments, attestation, encrypted channels, provider roles, and what our verification results actually prove.

Based on primary protocol and attestation standards

Direct answer

What makes AI inference confidential?

A TEE isolates the running model from the surrounding host. Remote attestation provides signed evidence about that protected environment. An encrypted channel keeps the prompt protected until it reaches the intended decryption key. A strong claim needs all three, plus evidence that the expected workload and request route were actually used.

01

Where does encryption end?

Find the first component that holds a decryption key and can see the prompt.

02

Is that key attested?

Verify that the decryption key belongs to the intended TEE, not merely to the provider.

03

Did this request use it?

Look for fresh, request-bound route evidence rather than an unrelated backend quote.

Channel summary

How do TEE-Terminated TLS and E2EE differ?

Both can keep plaintext inside an attested TEE. With TEE-terminated TLS, the TEE holds the HTTPS private key. With application E2EE, the client encrypts the AI payload to a separate attested key, so an outer API gateway can terminate HTTPS without reading that payload. A TEE-only gateway decrypts the prompt before the TEE and can read it.

Read the architecture deep dive
TEE-Terminated TLS
Ordinary HTTPS ends inside the attested workload.
Attested Application E2EE
The protected payload stays encrypted through the API gateway.
TEE-only Gateway
The gateway sees plaintext before forwarding it to a TEE backend.

Common questions

Frequently asked questions

Each answer is written to stand alone and has a stable URL that can be cited or shared.

What is confidential AI inference?

Confidential AI inference means running an AI model while limiting which surrounding systems and operators can read the prompt, response, or model data. It usually combines a TEE, remote attestation, and an encrypted channel. The actual guarantee depends on where that channel ends and what the attested software does.

What is a trusted execution environment (TEE)?

A TEE is an isolated area of a processor or accelerator. It is designed to keep the data and code inside it hidden from the host operating system, hypervisor, and cloud administrator. It reduces who must be trusted, but it is not a guarantee that the application itself is safe.

What is remote attestation?

Remote attestation is a signed hardware report. It can identify the TEE platform, security state, and a measurement of the software that started inside it. A verifier checks that report against the hardware vendor's root of trust and an explicit policy.

What does attestation not prove?

A valid quote does not prove that the measured code is well designed, that it has no logging or export feature, that it loaded the advertised model, or that your request reached it. Those claims need additional evidence such as reviewed source, reproducible builds, model measurements, key binding, and request-bound route evidence.

What does TLS termination mean?

TLS termination is the point where an HTTPS connection is decrypted. Before that point, intermediaries can forward encrypted bytes but cannot read the prompt. After that point, the component holding the TLS private key can read it. The security question is therefore not whether HTTPS is present, but where its private key lives.

What does end-to-end encryption mean here?

On this site, E2EE means that the client encrypts the AI payload to a key proven to belong to an attested TEE. An outer HTTPS connection can still end at an API gateway, but the gateway receives an encrypted prompt and cannot decrypt the protected payload.

Is E2EE always better than TEE-terminated TLS?

No. Both can create a cryptographic channel from the client to an attested workload. TEE-terminated TLS is easier for standard HTTPS clients and streaming. Application E2EE can work through a gateway or CDN that terminates TLS, but it needs client-side encryption, key verification, replay protection, and careful response handling.

Why is TLS still needed when the prompt uses E2EE?

TLS protects the outer API connection, credentials, headers, and protocol behavior from network attackers. Application E2EE adds a second protection boundary for the prompt and response. The two layers solve different parts of the problem.

What is a TEE-only gateway architecture?

The public gateway terminates HTTPS and sees the plaintext prompt, then forwards the request to a TEE backend. The TEE can still protect model execution from the backend host or cloud operator, but the gateway and anyone able to control it remain in the prompt trust boundary.

Does a verified backend prove that my request used it?

Not by itself. A provider or reseller can show a valid quote from one backend while routing a request somewhere else. Strong route evidence binds a fresh client challenge, requested model, backend identity, and response to the same attested key or signed receipt.

Can attestation identify a reseller and the real infrastructure provider?

It can contribute evidence, but the roles must be recorded separately. The API operator is the company you call and pay. The infrastructure operator runs the TEE or managed platform. A reseller may route different models to different infrastructure providers, so attribution should be per model route rather than assumed from the brand name.

What information can remain visible?

Encryption normally does not hide IP addresses, account identity, billing events, request timing, traffic size, or every header. Model names and tool metadata may also remain visible when they are needed for routing. Hiding those signals requires additional protocol and network measures.

Can code inside the TEE log or leak prompts?

Yes. A TEE protects code and data from the surrounding host; it does not make that code trustworthy. Malicious or flawed code inside the TEE can log, return, or transmit plaintext. Software measurements, source provenance, reproducible builds, egress controls, and an understandable policy are therefore important.

Why can hardware pass while the overall result is partial?

Hardware verification answers only part of the question. We mark a check partial when the hardware or channel evidence passes but another link, such as image provenance, source mapping, model identity, freshness, or request routing, is missing. Partial means useful evidence exists, not that the complete end-to-end claim is proven.

Continue

Move from definitions to evidence

Use the architecture guide for the full comparison, then inspect current provider and model evidence.

Primary references

Standards behind the answers

These sources define the underlying protocols and attestation architecture. Product claims still require provider-specific evidence.