Confidential computing protects the part of the AI lifecycle encryption used to miss

Introduction

An enterprise may be comfortable placing an encrypted dataset in cloud storage and sending it across an encrypted network connection. The objection can appear only when an AI workload starts, because inference, fine-tuning or another computation eventually requires the system to work with usable information.

At that point, model weights, prompts, intermediate representations, retrieval results or customer records can enter memory and accelerator paths where encryption at rest and encryption in transit no longer describe the complete exposure. The problem is not limited to personal data: proprietary models, credentials used by an agent and confidential outputs may all become valuable assets while the workload is running.

Confidential computing for AI workloads extends protection into the period when sensitive data and models are actually being processed, using hardware-backed trusted execution environments and attestation to narrow who and what must be trusted.

At a glance

• Encryption at rest protects stored data; encryption in transit protects data moving between systems. AI also creates sensitive data in use.
• Confidential computing uses hardware-backed trusted execution environments (TEEs) to isolate data and code during processing.
• Attestation lets another system verify the expected hardware and software state before releasing sensitive data, credentials, keys or model assets.
• AI accelerators increasingly need to participate in the confidential boundary rather than sitting outside it.
• Confidential computing reduces infrastructure trust requirements; it does not make unsafe code, excessive outputs or weak application controls harmless.
• Firmware, attestation policies, workload identities, image measurements and key-release conditions become production security state.

The old encryption boundary stopped before the computation

Enterprise security architecture is familiar with two data states. Information in storage can be encrypted at rest, while information crossing a network can be protected in transit.

Processing introduces a third state.

A CPU or GPU must be able to operate on usable information. Historically, that meant sensitive material becoming available somewhere inside the execution environment after storage or transport encryption had done its job.

The Confidential Computing Consortium defines confidential computing around this problem: protecting data in use through hardware-based, attested trusted execution environments. Its technical model treats confidentiality and integrity of data and code, hardware-backed isolation and attestation as central elements of the security boundary.

For AI, the implication is broader than protecting one customer record. The execution path may expose proprietary model weights, system prompts, embeddings, retrieved context, intermediate activations, credentials and confidential results.

The secure-computing boundary therefore has to follow those assets into active computation.

A TEE changes which infrastructure layers have to be trusted

A conventional virtual machine can have encrypted disks while still depending heavily on privileged infrastructure beneath the workload.

The hypervisor, host operating system, platform administrator and other privileged components may remain inside the practical trust boundary.

A hardware-backed TEE is intended to shrink that boundary. The objective is not to make the rest of the platform disappear, but to prevent ordinary infrastructure privilege from automatically becoming permission to inspect the protected workload’s memory.

Google describes Confidential VM as protecting code and data while they are being processed, complementing protections already applied to stored and transmitted information.

The architectural question changes accordingly.

Instead of relying only on who administers the machine, the enterprise can ask which execution environment has been cryptographically established as the environment allowed to see the protected material?

Attestation turns isolation into verifiable trust

Isolation by itself would leave another problem: how does the party supplying a sensitive dataset, model or secret know that the expected protected environment is actually running?

Attestation supplies evidence about that environment.

A confidential-computing platform can produce cryptographically verifiable claims about hardware and software state. Another system can evaluate those claims against policy before deciding whether the workload receives something sensitive.

Microsoft’s Azure documentation describes trusted platform measurements, PCR measurements, measured software state and application or workload measurements as part of the confidential-VM attestation model.

Google similarly describes attestation as the mechanism for establishing trust in confidential-computing environments.

Together, those controls allow hardware isolation to produce attestation evidence, let a relying system evaluate that evidence against policy and then make the release of a sensitive asset conditional on the result.

The machine does not merely claim to be protected. The party holding the asset can decide whether the evidence is good enough before releasing it.

Sensitive assets can be released only after the workload proves itself

One of the most useful confidential-computing patterns is attestation-gated access.

Instead of placing a decryption key, dataset, credential or model weight permanently inside an environment and trusting that the environment remains correct, access can be made conditional on evidence about what is running.

Google Confidential Space uses this model directly. Data owners can define attestation policies around properties of the confidential VM, the approved environment and the workload before protected resources are made available.

The policy may take account of workload identity, image measurements or other environment attributes. If the running workload no longer satisfies the agreed conditions, access can be refused.

A proprietary model therefore does not have to be released simply because a VM exists and has the correct network path. A sensitive dataset does not have to become accessible simply because an orchestration system says a job has started.

The environment can first prove that it is the environment the data or model owner agreed to trust.

AI makes the accelerator part of the confidential boundary

CPU protection alone is insufficient for many production AI workloads.

Inference and training routinely move data and model state onto GPUs. If the CPU is protected while the accelerator path exposes the same sensitive material, the confidential boundary has a gap precisely where much of the computation occurs.

Confidential GPU architectures attempt to extend the protected environment across that path.

Azure’s confidential GPU documentation describes architectures in which an AMD SEV-SNP confidential VM works with an NVIDIA H100 GPU so protected AI computation can extend beyond the CPU.

Google likewise supports specific Confidential VM GPU configurations, including confidential AI workloads using supported NVIDIA accelerators.

Google’s current Confidential VM release notes also record the August 7, 2026 general availability of its G4 confidential AI/ML configuration using AMD SEV and NVIDIA RTX PRO 6000 GPUs.

The result is a materially different security architecture: sensitive material does not have to leave a protected CPU environment merely because the model needs accelerator compute.

GPU attestation matters because the accelerator is executable infrastructure

Adding a confidential-capable GPU does not remove the need to establish trust in it.

The accelerator has firmware, drivers and security state of its own. Once it becomes part of the protected computation, those components matter to the trust decision.

NVIDIA’s attestation documentation supports local and remote attestation flows for confidential-computing GPUs, including H100 environments.

For an enterprise architecture, that means the evidence chain can extend beyond the VM.

The organisation may need assurance that the CPU environment, GPU, firmware, driver state and workload collectively satisfy the required security conditions before protected assets enter the execution path.

Attestation consequently becomes part of AI infrastructure orchestration rather than a one-time hardware certification exercise.

Confidential AI can separate workload ownership from infrastructure ownership

This becomes particularly useful when the owner of the sensitive asset does not own the environment where the computation runs.

A software company may want a customer to execute a proprietary model in the customer’s cloud environment without exposing the model weights to the customer’s infrastructure administrators.

The reverse relationship is equally important. A customer may need to provide highly sensitive data to an external AI provider without assuming that the provider’s privileged infrastructure operators should be able to inspect that data during processing.

These arrangements are difficult when infrastructure control automatically implies visibility into everything executed on that infrastructure.

A hardware-backed TEE plus attestation creates another option: both sides can agree to trust a specific measured workload rather than requiring one party to trust the other’s administrators with the underlying asset.

Confidential Space is designed around this type of separation between data owners, workload authors and workload operators.

The trusted entity becomes narrower: the approved computation.

Attestation policy becomes deployment policy

This architecture changes release management.

Suppose access to proprietary model weights is conditioned on the identity of a particular workload image. Updating that image can change the measurement used by the attestation policy.

The deployment may still work technically, yet the policy controlling access to the model may no longer accept it.

Google’s Confidential Space guidance supports authorization based on workload assertions and also supports signed-container approaches so policy does not always have to depend on one immutable image digest.

That makes confidential computing a software-supply-chain issue as well as an infrastructure issue.

Changes to workload images, firmware, drivers or attestation components can affect whether protected assets are released. Release engineering therefore needs to understand which measured properties are security-critical and which changes require updated policy or renewed approval.

Confidential computing does not protect a bad workload from itself

A TEE protects a workload from particular infrastructure threats.

It does not make the workload trustworthy merely because the workload runs inside one.

If application code sends sensitive information to an external service, confidential computing does not pull it back. If an AI agent is legitimately authorised to expose a secret through a tool call, hardware memory isolation does not correct the authorization decision. If a model generates a sensitive output, the protected environment may have worked exactly as designed while the application still creates a privacy or security problem.

Google’s Confidential Space guidance similarly warns operators to control what workloads write to logs and what information leaves through observable channels.

Confidential computing protects the execution environment.

Application behaviour, model behaviour and output governance remain separate control problems.

The trusted computing base becomes smaller, not nonexistent

Hardware-backed isolation is sometimes described too casually as removing trust.

It does not. Trust is relocated and reduced.

The enterprise now depends heavily on processor or accelerator security properties, firmware, attestation evidence, verification services and the policies used to interpret that evidence. Firmware state, verifier behaviour, evidence formats and remediation status therefore become part of the security lifecycle rather than background infrastructure details.

Google’s Confidential VM release notes illustrate that operational reality. The 2026 release history includes both new confidential-computing capabilities and security advisories affecting technologies such as Intel TDX and AMD SEV-SNP.

Those advisories are not an argument against confidential computing. They demonstrate why it must be operated as security infrastructure rather than purchased as a permanent hardware property.

The protected environment has to remain trustworthy after procurement.

Confidential GPU capability is improving, but architecture constraints remain

The available infrastructure is materially stronger than it was several years ago, but confidential AI should not be designed as though every ordinary accelerator topology already has an equivalent confidential configuration.

Support varies by provider, processor, accelerator, machine family and workload topology.

Google’s Confidential Space release notes record H100 GPU support becoming generally available on April 29, 2026, followed by general availability of H100 support with Intel Trust Authority attestation on September 15, 2026.

NVIDIA’s confidential-container support matrix likewise distinguishes supported configurations across H100/H200, B200/B300 and RTX PRO 6000 hardware, including differences between single- and multi-GPU environments.

These constraints can affect model sizing, training topology, inference architecture, resilience design and cost.

The security requirement can therefore reach all the way into capacity planning.

Confidential computing changes what procurement has to verify

“Supports confidential computing” is too shallow a procurement claim for a serious AI workload.

The buyer needs to establish the actual protected boundary: whether protection covers only CPU memory or also the GPU used by the model; what privileged administrators and infrastructure operators can observe; which hardware, firmware and workload properties can be attested; whether the enterprise can independently verify those claims; whether release of datasets, credentials or model weights can be conditioned on successful attestation; which changes invalidate the evidence; and what performance, topology or operational limitations appear when confidential mode is enabled.

Those checks should be tied to the workload rather than treated as a generic feature comparison.

A confidential CPU is not enough if sensitive assets leave that boundary during GPU inference. Attestation has limited value if no sensitive decision is actually conditioned on its result.

The architectural benefit appears when confidential computing is used to narrow the parties and infrastructure layers that must be trusted with data or model assets while they are actively being used.

Confidential computing belongs in the threat model before deployment

Confidential computing is easy to add late as a security-hardening feature.

The more valuable use cases tend to start earlier, with an exposure the enterprise is unwilling to accept.

That exposure might be a cloud administrator being technically capable of inspecting a proprietary model, a partner controlling infrastructure where a protected algorithm has to run, or a sensitive dataset needing GPU inference outside the data owner’s environment.

Only then should the architecture ask whether a TEE materially removes that exposure from the required trust model.

If it does, the design questions become concrete: identify the workload that must be measured, the claims that must be attested, the party that verifies them, the asset withheld until verification succeeds and the output allowed to leave afterwards.

The threat should come first, with the confidential-computing mechanism selected only after the trust exposure is clear.

That is stronger than enabling a confidential VM and assuming privacy improved because a platform checkbox changed state.

FAQs

What does confidential computing protect in an AI workload?

Confidential computing is designed to protect data and code while they are being processed inside a hardware-backed trusted execution environment. For AI, protected material can include sensitive input data, model weights, prompts, intermediate state, credentials and other assets that become active during computation.

How is confidential computing different from normal encryption?

Traditional encryption commonly protects data while stored or transmitted. Confidential computing extends protection into data in use, when a processor or accelerator is actively operating on the information. It typically combines hardware isolation with attestation so another party can verify the expected execution environment.

Why is attestation important for confidential AI?

Attestation provides cryptographic evidence about the hardware or software environment running a workload. An organisation can use that evidence before releasing a decryption key, dataset, credential or proprietary model. This turns confidential computing from an infrastructure claim into an enforceable access condition.

Do confidential GPUs matter for AI privacy?

They can matter substantially for GPU-based workloads. If sensitive data or model state leaves a protected CPU environment and enters an ordinary accelerator, part of the data-in-use exposure returns. Confidential GPU architectures aim to extend the protected execution boundary across the accelerator path.

Encryption now has to follow the computation

AI makes the old three-part diagram—database, network, application—less useful as a complete description of sensitive-data protection.

The valuable material moves through memory, accelerators, model runtimes and tool-connected execution environments.

Confidential computing addresses one particularly difficult part of that path: the moment information must be usable by a machine without automatically becoming visible to every privileged layer that operates the machine.

The important advance is not simply another form of encryption.

It is the ability to make sensitive computation conditional on a verifiable execution environment.

For AI infrastructure, that turns who is allowed to see the data while it is being used from an assumption into an architectural control.