Can Confidential Computing Keep An AI Provider From Reading Prompts?

August 3, 2026

It can keep plaintext prompts away from cloud operators and infrastructure administrators, but only when encryption, attestation, key release, inference code, logging, and network egress are all inside a verifiable design.

Yes, but only in a narrowly designed and verifiable system. Confidential computing can keep a plaintext AI prompt out of the normal reach of cloud administrators, hypervisors, host operating systems, and workload operators while the model processes it. It does not automatically stop the AI application itself from logging, copying, or sending that prompt elsewhere. The decisive questions are what runs inside the trusted execution environment, what is attested, who releases the keys, and where plaintext can travel next.

Who This Guide Is For

This guide is for people who:

evaluate an AI service that advertises confidential inference, secure enclaves, or trusted execution environments
need to protect source code, legal drafts, financial data, research, or other sensitive prompt content
want to know whether cloud-provider staff or an AI vendor can inspect prompts
compare ordinary encryption with encryption for data while it is being processed
review attestation, key-management, logging, and network controls for an enterprise AI deployment
need a practical checklist before accepting a provider's confidential-computing claim
are comparing a specialized confidential AI system with a privacy-focused hosted chat product such as OpenVeil

The short version is: a TEE can reduce who must be trusted, but it cannot make unreviewed application behavior trustworthy.

What Confidential Computing Changes

Ordinary cloud encryption usually covers two states:

Data at rest: stored prompts, files, databases, disks, and backups are encrypted.
Data in transit: TLS protects a request as it travels between systems.

AI inference creates a third state: data in use. A normal server has to make a prompt available in memory so software can tokenize it, run the model, and produce an answer. Infrastructure administrators, a compromised hypervisor, a debugger, a crash dump, or another privileged layer may sit near that plaintext boundary.

The Confidential Computing Consortium defines confidential computing around processing data inside a hardware-based, attested trusted execution environment, or TEE. NIST's current confidential-computing draft describes the same gap: encryption in use can extend protection to data while an AI workload acts on it in cloud memory.

A TEE is not merely an encrypted disk. It combines several properties:

memory confidentiality, so ordinary host inspection does not reveal protected runtime memory
memory and code integrity, so unauthorized modification can be detected or blocked
isolation, so the host OS, hypervisor, and other workloads do not get normal access to the protected environment
attestation, so another party can verify claims about the hardware and software state before trusting it with a key or prompt

That last property is essential. A provider saying "we use secure hardware" is weaker than a client proving that its request is going to an approved workload with an expected measurement.

The Strongest Prompt-Privacy Design

A defensible confidential-inference path looks like this:

The client requests fresh attestation evidence from the inference environment.
The client or an independent verifier checks the hardware, firmware, production status, workload identity, image digest, and other approved claims.
The encrypted channel is cryptographically bound to that attested environment.
The client sends the prompt only after verification succeeds.
A key-management service releases a decryption key only to the approved TEE.
The prompt becomes plaintext only inside the attested inference workload.
The model processes it without application logging or unauthorized network egress.
The result returns through the protected channel, and plaintext buffers and permitted records follow a documented lifecycle.

Google's current Prompt Encryption SDK codelab demonstrates this pattern with an open model served by vLLM inside Confidential Space. The client checks the software hash, hardware model, and launch configuration through attested TLS. If attestation fails, the prompt is not sent.

NIST describes a complementary key-release design. The TEE presents evidence about its identity, measured code, and security state. A key service compares that evidence with policy and releases the input, model, or output decryption key only when the environment passes. The plaintext key is not exposed outside the TEE.

This can materially change the provider relationship. The infrastructure operator may run the machine yet lack the normal technical path to read its protected memory. But that result depends on the entire chain, not the processor feature alone.

What Is Confirmed

A TEE Can Isolate Runtime Memory From Privileged Infrastructure

Current Google Cloud confidential-computing documentation says TEEs protect data in use in isolated environments. Its Confidential Space security overview describes a model in which the workload operator can administer the cloud project but does not receive access to protected data or results.

NVIDIA's current confidential-computing reference architecture says the protected design can stop host administrators and ordinary infrastructure tooling from reading decrypted guest memory, model weights, or keys.

That is a real improvement over trusting every privileged infrastructure layer.

Attestation Can Verify More Than A Provider Name

Google Cloud Attestation can produce cryptographic claims about supported confidential environments. Confidential Space policies can check the workload container digest, confidential image state, hardware technology, zone, project, and whether a production rather than debug image is running.

An attestation result is therefore more useful when it answers a precise question: "Is this exact approved workload running in a supported production TEE?" It is less useful when the policy merely confirms that some confidential VM exists.

Key Release Can Make Attestation Enforceable

Attestation by itself is evidence. Key release turns that evidence into a gate. The sensitive prompt or model stays encrypted unless the environment satisfies policy.

This matters because a dashboard badge cannot stop a request from reaching the wrong server. A client-side or data-owner-controlled key policy can.

Confidential AI Can Protect Both Prompts And Model Weights

The two sides may distrust each other. A customer wants to protect prompts and files; a model developer wants to protect proprietary weights. Confidential inference can allow both assets to enter the same attested environment without exposing them through normal operator access.

Microsoft's Confidential AI overview describes this goal as protecting inference requests and responses from the model developer, service operations, and cloud provider. Google provides a Confidential Space model-sharing walkthrough built around a similar separation of roles.

What Is Still Unclear In Many Provider Claims

Who Does "The Provider" Mean?

An AI service can involve several different parties:

the cloud infrastructure operator
the TEE hardware and attestation vendors
the company that wrote the inference image
the model developer
the application gateway and account service
the key-management administrator
logging, security, billing, and support systems

A design may exclude the cloud host from plaintext while the application developer intentionally remains able to receive it. "Protected from the provider" is not meaningful until the provider role is named.

What Exactly Is Measured And Attested?

An attested VM does not necessarily prove the identity of every container, model, configuration file, extension, or gateway involved in the request. A useful policy should identify the workload that can see plaintext, not merely the machine family.

Updates also complicate verification. A new image digest may be legitimate but different from the previously approved workload. Users need to know who approves those changes and whether the service fails closed when evidence no longer matches.

Does Plaintext Exist Before The TEE?

If an ordinary API gateway terminates TLS, parses the prompt, performs moderation, builds a trace, or writes request logs before forwarding data to the TEE, confidential inference begins too late.

The strongest design encrypts or protects the request from the client to the attested workload. Google's Prompt Encryption SDK is notable because it binds the request channel to attestation before transmitting the body.

Can The Workload Log Or Export The Prompt?

NVIDIA's threat model is explicit: confidential computing does not stop a malicious guest image, vulnerable inference code, or application-level payload logging. A correctly attested program can still be the wrong program from a privacy perspective.

The workload may also have outbound network access. If it can send plaintext to analytics, moderation, search, storage, or another model API, the TEE has protected the prompt only until the application deliberately moves it elsewhere.

Who Controls The Attestation And Key Policy?

If the same party can change the workload, rewrite the attestation policy, and release the keys without independent review, the architecture may provide less separation than the marketing suggests.

Independent verification is not mandatory for every use case, but the trust chain should be disclosed. A customer should know whether attestation is checked by the client, the cloud provider, the AI vendor, or an independent service, and who can approve new measurements.

Protection Matrix: What A TEE Can And Cannot Prove

Question	Strong confidential-computing answer	What still needs separate proof
Can a host admin read live prompt memory?	Hardware-backed isolation blocks ordinary host and hypervisor inspection	TEE vulnerabilities, physical attacks, and the approved threat model
Is the request reaching the expected workload?	Fresh remote attestation checks approved hardware and software measurements	Who defines policy and how updates are authorized
Can the gateway see plaintext?	Client-to-TEE attested encryption keeps the body protected until the enclave	DNS, traffic metadata, account identity, rate limits, and denial of service
Can the application log the prompt?	Only if reviewed code and policy prohibit or technically constrain logging	Log configuration, crash reporting, traces, debug modes, and retention
Can the workload send the prompt elsewhere?	Egress restrictions can limit destinations and protocols	Covert channels, approved external services, and output leakage
Does attestation prove the model is honest?	It proves measured code and configuration are running	Whether that code is safe, private, correct, or free of malicious behavior
Does the TEE delete the prompt?	It can protect transient memory and sealed storage	Application retention, backups, audit records, output copies, and deletion workflows
Does it prevent all attacks?	No	Side channels, supply-chain flaws, vulnerable code, compromised policy administrators, physical attack, and denial of service remain separate

A Seven-Question Buyer Checklist

1. Which People And Systems Are Excluded From Plaintext?

Ask for roles, not slogans. Can cloud administrators read prompts? Can the AI application's engineers? Can support staff? Can the model vendor? Can a security-review system receive a copy?

2. Does The Client Verify Fresh Attestation?

Look for a documented protocol, supported hardware claims, nonce or freshness protection, verified software measurements, and a fail-closed result. A static compliance report is not a substitute for per-environment attestation.

3. Is The Request Protected All The Way To The TEE?

Determine where TLS terminates and where the first plaintext copy exists. Ask whether load balancers, API gateways, web application firewalls, moderation services, or tracing systems can see the request body.

4. What Workload And Configuration Does Policy Approve?

The policy should cover enough of the trusted computing base to distinguish the intended inference server from an altered or debug workload. Ask whether it binds the container or application image, model version, firmware state, and production support status.

5. Who Can Change Code Or Release Keys?

Review separation of duties. The party that deploys a new image should not automatically gain an invisible path around approval and key-release policy.

6. What Logging, Egress, And Tool Paths Exist?

Inventory prompt logs, traces, crash reports, abuse monitoring, web search, connectors, file parsers, model routers, and outbound APIs. Confidential memory does not erase these paths.

7. What Evidence Can A Customer Actually Inspect?

Useful evidence can include attestation claims, signed image digests, source or reproducible-build information, an egress policy, retention documentation, independent assessment, and a description of the threat model and exclusions.

If a provider cannot explain these seven points, "confidential AI" should be treated as an architecture claim that still needs validation, not as proof that no one can read prompts.

What Confidential Computing Does Not Mean

It Does Not Mean The AI Application Is Trustworthy

Attestation can prove that known code is running. It does not prove that the code avoids logging, produces correct answers, resists prompt injection, or follows a good privacy policy.

It Does Not Mean No Provider Processing

The model must still process the prompt. Confidential computing changes who can observe that processing and under what technical conditions; it does not make hosted inference local or eliminate the service provider.

It Does Not Mean Zero Logs Or Immediate Deletion

Account, billing, security, rate-limit, network, and audit records can exist outside prompt content. The application can also create allowed records inside or after the TEE. Retention and deletion require their own documented controls.

It Does Not Mean Fully Offline Or Anonymous

A confidential cloud workload remains a networked service. It can learn account, timing, traffic, and routing metadata even if prompt contents stay encrypted until the TEE. An authenticated service also retains its normal account relationship.

It Does Not Mean Side-Channel Or Supply-Chain Immunity

Google's Confidential Space threat model excludes some software supply-chain attacks and cloud VM escapes. NVIDIA lists malicious guest code, side channels, compromised key-policy administration, physical attack, and denial of service outside the basic protection claim. The exact boundary varies by platform.

It Does Not Create Compliance By Itself

Confidential computing can support a regulated architecture, but hardware features alone do not establish HIPAA, GDPR, contractual, or sector-specific compliance. Governance, access controls, contracts, risk assessment, retention, incident response, and operating practice still matter.

Where OpenVeil Fits

OpenVeil is a paid, privacy-focused AI chat workspace with browser-local history and no server-side chat-history record for normal private chat sessions. OpenVeil does not use prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.

OpenVeil is not documented as a confidential-computing or provider-blind inference service. It does not claim that OpenVeil or necessary providers are cryptographically unable to process active prompts. Active requests may still be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers.

That is a different trust boundary. Browser-local history limits the normal server-side chat-history archive; confidential computing can limit privileged visibility into data during processing. A system could use either control, both controls, or neither. One does not substitute for the other.

Read Does Encryption Make An AI Chat Private?, Who Holds The Encryption Keys For An AI Chat?, and What To Check Before Trusting Any AI Privacy Claim. If OpenVeil's documented hosted-chat tradeoff fits your needs, review the OpenVeil privacy policy and create an account.

Frequently Asked Questions

Can A Cloud Provider Read Data Inside A TEE?

A correctly implemented TEE is designed to prevent ordinary cloud administrators, host software, and hypervisors from reading protected runtime memory. The answer still depends on the hardware threat model, attested software, debug state, vulnerabilities, and whether plaintext appears outside the TEE.

Can The AI Company Still Read My Prompt?

Possibly. If the AI company wrote the workload, controls a plaintext gateway, enables application logging, receives moderation copies, permits network egress, or controls key release, it may retain a path to the prompt. Confidential computing can exclude infrastructure operators without automatically excluding the application provider.

What Does Remote Attestation Prove?

Remote attestation provides signed evidence about an environment and its measured state. A verifier compares those claims with policy. It proves only what the evidence and policy cover; it does not prove that approved code is bug-free or privacy-preserving.

Does HTTPS Already Protect Prompts From The Provider?

No. HTTPS protects data in transit from network observers. The server normally decrypts the request. Attested client-to-TEE encryption can delay plaintext exposure until the request reaches a verified protected workload.

Can A TEE Stop Prompt Logging?

Not by itself. Logging is application behavior. The attested workload must be designed and configured not to log sensitive payloads, and adjacent gateways, traces, crash reporters, and security systems must follow the same boundary.

Does Confidential Computing Protect Model Outputs?

It can protect outputs while they remain inside the TEE and during an attested encrypted return channel. Once an output reaches a browser, application database, log, downstream tool, or user device, those systems define the next boundary.

Is Open-Weight Local AI The Same As Confidential AI?

No. Open-weight local inference can keep processing on hardware you control, subject to the surrounding application's network and storage behavior. Confidential AI uses attested protected execution to reduce trust in infrastructure even when the workload runs on someone else's machine. Each approach solves a different custody problem.

Is Confidential Computing Better Than Client-Side Encryption?

They are complementary. Client-side encryption can protect a prompt before transmission, but an ordinary hosted model cannot process ciphertext. Confidential computing can provide a verified place to decrypt and process it. Fully homomorphic encryption and secure multi-party computation pursue other designs with different capability and performance tradeoffs.

The Bottom Line

Confidential computing can keep AI prompts away from cloud administrators and other privileged infrastructure layers while inference runs. The strongest design verifies the exact workload, binds an encrypted client channel to fresh attestation, and releases keys only inside an approved production TEE.

That does not automatically keep prompts away from the AI application provider. Known code can still log, retain, or export plaintext; gateways and security tools can see data before it reaches the enclave; and attestation, key policy, software supply chain, egress, retention, and deletion remain separate controls.

The practical test is not "Does this service use a TEE?" It is: Which exact code can see plaintext, who approved it, who can change it, where can it send data, and what cryptographic evidence prevents the request from going anywhere else?

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.