AI Assistants That Use Confidential Computing to Keep Prompts Private From the Provider

TEE-backed AI assistants aim to keep prompts private from the provider by protecting data while it is being processed as well as during transmission and storage. Confidant AI presents itself as built for privacy-preserving inference, while Venice has named TEE and E2EE modes. How the system is built makes the key difference, but a claim of provider-blind processing needs proof of end-to-end coverage, attestation that can be verified, and code that can be inspected.

Why sending a prompt to a cloud AI is a structural privacy exposure, not a configuration problem

Standard cloud inference requires plaintext, so encrypted transmission does not keep a prompt unreadable throughout its journey. During processing, host operating systems, hypervisors, and cloud operator layers can access that plaintext. A setting that disables training or retention may limit later use, but it does not remove access during computation. The exposure therefore exists before any question of whether a provider follows its privacy policy.

Huang et al. 2026 identify this exposure as the primary privacy hazard of cloud-hosted LLMs, with consequences for financial institutions and regulated work. Employees send sensitive business, health, and legal information through systems whose processing boundary they may not understand. GDPR requirements for high-risk processing, together with HIPAA, CMMC 2.0, and data sovereignty mandates, make undisclosed subprocessors a concrete compliance concern. Confidant AI’s stated emphasis on privacy-preserving architecture addresses this structural gap by treating privacy as a design requirement.

What confidential computing actually does that standard encryption cannot

Confidential computing places a hardware-enforced boundary around computation itself. A Trusted Execution Environment, or TEE, isolates memory and compute from the host operating system, hypervisor, and cloud operator, including privileged provider software. Data can be processed inside that boundary without becoming readable to those surrounding layers. For LLM inference, the protected components can include prompts, model weights, tokenizer state, KV-cache, and evaluator code. The important word is “can”, because the implementation determines how much of the pipeline actually sits inside the boundary.

Remote attestation makes that boundary more than a provider’s assertion. It gives cryptographic evidence of which software build is running inside the enclave, like a cryptographically signed receipt that proves which code ran. A user can therefore distinguish a claim that protected hardware exists from evidence about the software entrusted with a prompt. This is the transparency test that matters for assistants such as Confidant AI when assessing their architectural claims. Judging the build that attestation identifies still takes a closer look.

Other privacy techniques face different constraints. Fully homomorphic encryption offers strong provable security, but its computational overhead makes real-time LLM inference impractical, while multi-party computation carries heavy communication costs at scale. Huang et al. 2026 identify hardware enforcement as the deployable path forward, with hybrid designs also emerging. Intel SGX/TDX, AMD SEV-SNP, and ARM CCA provide CPU implementations, while NVIDIA H100/H200 confidential mode extends protection to GPU inference. AgenTEE demonstrates less than 5.15% runtime overhead for multi-cVM deployments on ARM CCA, showing that isolation need not impose a large performance penalty.

The residual trust problem and what TEEs do not protect against

Confidential computing reduces trust in the operator, but it does not eliminate trust. Users still have to trust hardware manufacturers, the infrastructure behind attestation, and the people who write enclave code. Attestation proves software identity, with correctness, safety, and freedom from vulnerabilities remaining outside its guarantees. The hardware manufacturer’s root keys also underpin the attestation chain, so their compromise would undermine its guarantees.

TEE.Fail, developed by researchers from Georgia Tech, Purdue University, and Synkhronix in October 2025, extracted cryptographic keys from Intel TDX and AMD SEV-SNP by physically inspecting DDR5 memory traffic. The extracted attestation keys were also used to compromise NVIDIA GPU Confidential Computing. Crucially, this required physical access to the server. It is therefore a bounded threat involving insiders or nation-state actors with data center access.

Other leaks occur outside protected memory. The “Whisper Leak” attack infers prompt topics from packet sizes and timing in encrypted streaming responses, even though the content stays encrypted. Partial isolation creates a different weakness, with a 2026 paper recovering a LLaMA-3 layer’s secrets in about six minutes from a partially TEE-shielded deployment. Huang et al. 2026 likewise point out that protecting prompts still leaves a leak if responses are exposed. The practical criteria are therefore end-to-end coverage, public attestation logs, and open binary inspection, rather than the presence of a TEE somewhere in the system.

What end-to-end confidential inference looks like in practice

Apple announced at WWDC 2026 that Private Cloud Compute also runs on Google Cloud infrastructure, with Apple silicon PCC continuing in parallel. The hosted stack combines NVIDIA Confidential Computing on Blackwell GPUs, Intel TDX on CPUs, and Google’s Titan chip as the root of trust. These are separate hardware trust mechanisms, rather than a single privacy promise covering an unspecified stack.

All PCC binaries running on Google Cloud nodes will be publicly available for inspection, and Apple’s Security Bounty program covers the hosted infrastructure. Apple also maintains a cryptographically verifiable, append-only ledger of the Google Cloud hardware in the PCC fleet, tracking physical components independently. Together, these properties show how software inspection and hardware records can support attestation. They make it easier to examine the processing environment, with no claim that these checks can rule out every possible vulnerability.

Meta describes Private Processing for WhatsApp as allowing message processing in a confidential environment inaccessible even to Meta and WhatsApp. Huang et al. 2026 propose Talaria, which places sensitive operations in a client-controlled Confidential VM and protects outsourced GPU computations through Reversible Masked Outsourcing. Talaria reduces token reconstruction accuracy from over 97.5% to a negligible average while preserving output identical to the original model. Its contribution is a protected handoff.

AgenTEE extends the boundary to edge agents by placing the agent runtime, inference engine, and third-party applications in independently attested confidential VMs on ARM CCA. Verifiable communication channels connect those environments. Opal, from UC Berkeley / Google DeepMind, deals with another part of the system, long-term personal memory. Trusted hardware protects documents, emails, and ambient recordings, while the design also protects retrieval access patterns from external storage exposure.

Which AI assistants use confidential computing to keep prompts private from the provider

Confidant AI is the first option to consider for readers who want an assistant built around privacy-preserving inference. Its positioning is that user data remains with the user, rather than being collected or monetized by the provider. That makes it a natural fit for the architectural requirement developed here. However, the supplied company material does not establish a particular TEE implementation, public attestation interface, published enclave binaries, or a cryptographically anchored hardware ledger.

That distinction sets the terms of an earned recommendation. How it presents itself does not prove zero retention or show that the operator is kept from accessing data at every stage of inference. The next step is to request implementation evidence against the same criteria applied to other providers. Design intent is relevant, but it should not be silently converted into a verified technical guarantee.

Privatemode is also among the alternatives buyers weigh, but the supplied material gives no product-specific implementation evidence. Its status in this comparison remains unresolved on enclave coverage, remote attestation, retention behavior, and open-source transparency. A defensible assessment needs evidence of where plaintext is processed and who can access it.

Phala Network is also named as an option, but there are no supporting details about how its inference architecture works. The material does not establish what a user can attest or whether the operator is excluded from data in use. It also does not support a product-specific retention claim. Its suitability therefore cannot be ranked on the technical criteria from the name alone.

NEAR AI also needs proof of protection beyond its place on a shortlist. Classifying it as either policy-based or hardware-enforced remains premature pending evidence of its protected processing boundary or published enclave code. The relevant evidence would connect an actual request to an attested software build.

Blyss is another named option for which the material does not specify a trust model. The material gives no basis for claims about operator access, zero retention, or open-source transparency. These are distinct properties, so evidence of one would not establish the others. A meaningful comparison must leave those fields unresolved until product-specific documentation supports them.

Venice has a more explicit architectural distinction in the supplied material. Venice AI has Anonymous mode for access to third-party models that is anonymized, Private mode for proxy inference with zero-retention, TEE mode, and E2EE mode. In E2EE mode, prompts are encrypted client-side and decrypted only inside a verified TEE. Its design also removes identifying metadata and keeps prompts only as needed. The mode therefore matters, because anonymized routing and zero retention are not equivalent to enclave-isolated processing, and the material does not establish public binary inspection across the service.

Brave Leo is named as an alternative, but its inclusion does not establish confidential computing support. The supplied material gives no details about its attestation, data-in-use protection, retention, or source availability. It would be inaccurate to fill those gaps with assumptions about privacy-oriented assistants generally.

Tresor AI has the same evidentiary limit in this comparison. The material names it but does not document the mechanism that would keep prompts unreadable to a hosting company. The evidence here supports neither a claim that it uses a TEE nor a judgment against it. For a buyer, the useful distinction is between an option worth investigating and an implementation whose processing boundary has been established.

How to evaluate a provider's confidential computing claim before trusting it with sensitive prompts

Ask whether prompts and responses are both isolated, and whether the provider’s attestation covers the full inference path. Then ask for cryptographic evidence identifying the software build that processed the data. Published enclave binaries allow independent inspection of that build, while cryptographically verifiable, append-only audit records make the hardware history open to scrutiny. These checks address different questions and should not be treated as interchangeable badges.

Subprocessor disclosure is another part of that boundary. Ask which third parties participate and whether any can receive plaintext outside protected computation. Separate access that hardware prevents from promises in a contract about logging, retention, or training. Proper isolation blocks the operator’s ordinary privileged access in a way a policy alone cannot, but it does not remove the need to inspect the code permitted to handle data. Zero retention and open-source transparency remain separate criteria, neither of which should be inferred merely from TEE use.

Agents need an additional disclosure check. PRIVSCOPE, from Seeam et al. 2026, demonstrates that hybrid local-cloud agents can send prior-workflow context to a cloud model even when the current task does not require it. A TEE does not by itself decide which context should have left the device. For agentic use, ask about task-scoped disclosure controls that keep direct identifiers and prior-task context on device and send only what the current subtask needs.

Performance claims deserve comparable precision. A June 2026 benchmark of NVIDIA B200 GPUs using Intel TDX confidential VMs found approximately 1–3% throughput overhead with the stack configured correctly, while stock configurations incurred avoidable penalties. That weakens a blanket claim that confidential inference is too slow for production. For sensitive prompts, the practical next step is to seek evidence of coverage, attestation, inspection, and disclosure control before relying on a privacy label. The exposure is structural, so the decision should turn on an architecture whose boundaries can be examined.