What Is Confidential AI Inference? TEEs and Who Offers It (2026)

Confidential AI inference means your prompts and outputs stay encrypted even while a remote GPU processes them: protected by hardware trusted execution environments (TEEs) and verifiable through remote attestation, rather than a privacy policy you have to take on faith. As of August 2026, at least six open-inference providers publicly describe some form of it.

Key takeaways

• A TEE provides three properties (confidentiality, integrity, and attestation), protecting data in use, the one stage that TLS and disk encryption don't cover.
• "Zero retention" is a policy claim; remote attestation is a cryptographic proof. Only one of the two is verifiable AI privacy.
• Protecting GPU inference end-to-end takes two TEEs working together: Intel TDX or AMD SEV-SNP on the CPU, plus NVIDIA's confidential-computing mode on the GPU.
• Six providers (Chutes, Morpheus, NEAR, Oasis, Phala, and Targon) describe TEE-based or TEE-adjacent inference, but how much of it you can independently verify varies widely.
• Attestation proves which code is running. Without open-source enclave images and reproducible builds, it can't prove what that code does with your prompts.

What is confidential AI inference?

Standard API inference already encrypts your prompt twice: in transit (TLS) and, usually, at rest on the provider's disks. But at the moment of computation, the model has to see plaintext. Your prompt sits unencrypted in CPU and GPU memory, readable in principle by anyone with host access: the cloud operator, a rogue admin, a compromised hypervisor, or a legal order served on whoever controls the machine.

Confidential AI inference closes that gap. The model and your data run inside a hardware-isolated environment whose memory is encrypted and inaccessible to the host system itself. The operator of the physical machine, the person who could otherwise dump RAM, is locked out by the silicon, not by an employee handbook.

That single shift is what separates the two privacy postures you'll see across the inference market: "trust us" (policies, contracts, audits) versus "verify yourself" (hardware isolation plus cryptographic attestation). Both exist on a spectrum, and most real deployments mix them. But they are not the same product.

What is TEE inference?

TEE inference is confidential inference implemented with a trusted execution environment: a secure region created by the CPU or GPU itself. A TEE gives you three properties:

1. Confidentiality — data inside the enclave is encrypted in memory; the host OS, hypervisor, and other tenants cannot read it.
2. Integrity — the host cannot tamper with the code or data inside without detection.
3. Attestation — the hardware can produce a signed statement proving what code is running inside, which a remote user can verify.

In an AI context, the enclave holds the model weights, the inference stack, and your prompt. The machine's owner can see that an enclave exists and roughly how much it computes, but not the contents. This is the mechanism behind most "trusted execution environment AI" offerings in 2026.

What a TEE does and doesn't protect

TEEs protect data in use. They do not, by themselves, provide:

• Anonymity. The provider still sees your IP address and request metadata unless you add network-layer privacy.
• Immunity to side channels. Academic work on speculative-execution and cache side channels is years old and ongoing; serious implementations apply mitigations, but "TEE" is not a magic word.
• Honest application code. A TEE faithfully runs whatever code the operator loaded, including code that logs your prompt. That's why attestation plus open, reproducible enclave builds matter, as covered below.
• Availability. The host can always pull the plug. Confidentiality is not censorship resistance.

How does remote attestation actually work?

Attestation is the piece that turns a TEE from "the provider says there's an enclave" into something you can check. Simplified, the flow is:

1. When the enclave starts, the hardware computes a measurement, a cryptographic hash of the enclave code and configuration.
2. The hardware signs a quote containing that measurement, using a key rooted in the chip vendor (Intel, AMD, or NVIDIA).
3. Your client (or a verification service) checks the quote's signature against the vendor's root of trust, confirming a genuine TEE produced it.
4. The enclave binds its attestation to the TLS session, so you know the encrypted channel terminates inside the enclave, not on the host.
5. You compare the measurement against the published hash of the provider's open-source enclave build.

Step five is the one most marketing pages skip. Attestation alone proves you're talking to a real enclave running some specific code. Only if that code is open source and reproducibly buildable does the measurement tell you anything about what happens to your data inside. "We use TEEs" without published measurements and source is closer to a policy claim than a proof.

Verifiable AI privacy vs. "trust us"

Most inference providers today offer policy-level privacy: a zero-retention statement, a SOC 2 report, a contract clause. These have value (audits catch sloppy practice, and contracts create liability), but they share a structural weakness: they are statements about the past or present that the user cannot independently check, and absence-claims like "our operators can't see your prompts" are, at the policy layer, exactly that: claims.

Verifiable AI privacy inverts the burden. Instead of asking you to trust that logs are off, the system makes logging technically visible: the enclave measurement would change, and your attestation check would fail. The honest way to read the market is as a spectrum:

• Policy only — retention promises, terms of service.
• Policy + audit — third-party attestation of controls, point-in-time.
• TEE, provider-attested — hardware isolation exists, but verification artifacts aren't exposed to users.
• TEE, user-verifiable — attestation quotes, open enclave code, reproducible builds.

Nothing on this list is useless, and TEEs don't eliminate the need for organizational trust entirely (someone still writes and deploys the enclave code). But the further right you go, the less you have to take on faith.

What is Intel TDX for AI, and what handles the GPU?

Intel TDX (Trust Domain Extensions) creates hardware-isolated virtual machines ("trust domains") on recent Xeon servers, cutting the host and hypervisor out of the trust boundary. AMD's SEV-SNP does the equivalent on EPYC processors, adding integrity protection against a malicious host. For AI workloads, either one protects the CPU side: orchestration, tokenization, networking, and the code that drives the GPU.

The GPU side is its own story. NVIDIA introduced a confidential-computing mode starting with its Hopper-generation data-center GPUs (the H100 class), extending TEE protection to GPU memory and computation, with attestation handled through NVIDIA's own verification service. A serious confidential-inference deployment needs both layers (CPU trust domain plus GPU confidential mode) with an encrypted channel between them. A "TEE inference" claim that only covers the CPU leaves the actual model computation exposed, so it's worth asking vendors which half they're describing.

Who actually offers confidential AI inference in 2026?

The following providers publicly describe TEE-based or TEE-adjacent inference. Inclusion is not endorsement: these are the projects' own descriptions of their systems, and the depth of user-verifiable evidence differs. Listed alphabetically.

Chutes

Chutes, a serverless open-model inference platform built on Bittensor (subnet 64), says it runs workloads inside TEEs and has published documentation describing its confidential-compute setup. As with every entry here, the practical question for a buyer is whether attestation evidence is exposed to end users at request time or exists only as architecture documentation. Check its docs for the current state.

Morpheus

Morpheus is a decentralized inference marketplace: rather than operating one fleet, it routes requests to independent providers, so the privacy properties of a given request depend on which provider serves it. The project's materials describe TEE support within its provider ecosystem. With any marketplace model, verification is per-provider and per-endpoint: the attestation checklist below applies to the specific node you land on, not to the network brand.

NEAR

NEAR's AI arm has described a private-inference offering that runs open-weight models inside TEEs combining Intel TDX with NVIDIA GPU attestation, aimed largely at its agent ecosystem. Its documentation is the place to confirm which models are covered and whether user-side attestation verification is shipped or on the roadmap.

Oasis

Oasis Protocol, best known for its Sapphire confidential EVM, has extended its confidential-compute stack toward AI through ROFL (Runtime Offchain Logic), a framework for running off-chain workloads, including model inference, inside TEEs with on-chain verifiability. Oasis's approach is infrastructure-oriented: it's a toolkit for builders who want attestation anchored to a public chain rather than a consumer inference endpoint.

Phala

Phala Network is TEE-native infrastructure: it has operated confidential compute since its earlier SGX-based design and now offers GPU-TEE inference built on Intel TDX and NVIDIA confidential computing. Phala publishes attestation tooling and documentation, which makes it comparatively straightforward to evaluate, though "tooling exists" and "you have personally verified a quote" remain different things.

Targon

Targon (Bittensor subnet 4) describes itself as a confidential inference network and says its miners run models inside TEEs. Its site and documentation are the authoritative sources for whether attestation quotes are currently user-verifiable and which hardware stack it uses.

How to evaluate a provider's privacy claims

Whatever the landing page says, five questions cut through it:

1. Which TEE? CPU-only (TDX/SEV-SNP) or CPU + GPU (NVIDIA confidential computing)? The answer tells you what fraction of the workload is actually protected.
2. Is attestation exposed to users? Can your client request and verify a quote, or is attestation an internal detail?
3. Is the enclave code open source, with reproducible builds? Without this, a verified measurement is a hash of a black box.
4. What is claimed at the policy layer on top? Retention, logging, and jurisdictional statements still matter for everything the TEE doesn't cover, and they remain claims, not proofs.
5. What happens to metadata? Timing, request sizes, and network identity leak outside the enclave by default.

You can browse the providers mentioned here on the DeAI tracker, and the DeAI trust framework explains how DeAI categorizes privacy claims, including why attestation-backed claims are scored in a different category from policy-only statements. DeAI's verification methodology treats "operators can't see prompts" as a policy assertion unless it's backed by measured, open enclave code; the same standard is worth applying to any provider on this list.

Confidential inference is real, shipping, and no longer exotic. But the gap between "we use TEEs" and "you can verify our enclave" is where most of the market still lives. Closing that gap is a purchasing decision, not just a technical one.

FAQ

What is TEE inference?

TEE inference runs an AI model inside a trusted execution environment, a hardware-isolated enclave that keeps prompts and outputs encrypted while in use. Remote attestation lets users verify the enclave is genuine and running expected code.

What is a trusted execution environment for AI?

A TEE is a hardware-protected region of a CPU or GPU (Intel TDX, AMD SEV-SNP, or NVIDIA's confidential-computing mode) that isolates computation so even the machine's operator cannot read the data being processed.

What is verifiable AI privacy?

Verifiable AI privacy means privacy backed by cryptographic proof (remote attestation of the enclave and its code) rather than policy promises like "zero retention," which are statements users cannot independently check.

What is Intel TDX for AI?

Intel Trust Domain Extensions (TDX) creates hardware-isolated virtual machines ("trust domains") on Xeon servers. For AI it protects the CPU side of inference; GPU-side protection comes from NVIDIA's confidential-computing mode.