Back to blog

Confidential Computing for AI Workloads: Protecting Data in Use

AICybersecurityData SovereigntySoftware Architecture

AI workloads increasingly process confidential customer data, internal documents, and proprietary models on external infrastructure. Encryption at rest and in transit is not sufficient because data must be readable in memory during computation. Confidential Computing extends the protection boundary to that processing stage.

What Confidential Computing Protects in AI Workloads

Confidential Computing performs computation inside a hardware-based, attested Trusted Execution Environment (TEE). It isolates code and data from the host operating system, hypervisor, and other workloads. The May 2026 draft of NIST IR 8320E describes remote attestation as a critical component for confidential cloud workloads.

This is about more than encrypted memory. A robust design combines several controls:

  • Isolated execution: Prompts, RAG context, model weights, and intermediate results are processed inside the TEE.
  • Remote attestation: Cryptographic measurements provide evidence of which hardware, firmware, and software were actually started.
  • Conditional key release: A key management system releases keys only when attestation satisfies a defined policy.
  • Protected data path: Inputs, outputs, logs, and connections between CPU and GPU must not leave the trust boundary without control.

Technologies such as AMD SEV-SNP, Intel TDX, and NVIDIA Confidential Computing implement these principles differently. A “confidential VM” is therefore not an interchangeable product feature. Teams need to establish which components are protected, who verifies attestations, and which privileged access remains outside the TEE.

How Teams Should Introduce Confidential Computing

The right starting point is a specific threat model, not enabling a cloud option. An internal knowledge assistant using public documents needs different controls from AI inference over production, health, or manufacturing data.

For a robust introduction, teams should:

  • Classify data and adversaries: Establish whether protection is required from other tenants, cloud administrators, compromised hosts, or participating data partners.
  • Choose the smallest protection boundary: Weigh a confidential VM, container, or enclave. A smaller trusted computing base reduces risk but often increases integration effort.
  • Enforce attestation: Bind keys and sensitive data to approved measurements. An attestation report without a technical access decision offers little protection.
  • Secure inputs and outputs: Review telemetry, error reports, caches, and model responses for data leakage. A TEE does not repair an insecure application.
  • Plan operations and updates: New images change measurements. Patch processes, policy rollout, recovery, and cost and performance tests belong before production.

Warning signs include treating a TEE as a blanket compliance argument, storing prompt logs without encryption, or placing long-lived credentials inside the workload. Missing ownership for attestation policies also turns a technical capability into a promise that nobody can verify.

Why This Matters

Confidential Computing can narrow the trust boundary of AI products. This is particularly relevant when several companies analyse data together, protect sensitive models, or permit cloud operations without giving the operator access to plaintext data.

The additional complexity makes economic sense where it addresses a specific customer objection, contractual requirement, or material loss scenario. For low-risk workloads, conventional encryption with sound identity and access management may be sufficient.

The technology replaces neither data minimisation nor secure software development, permissions, and supplier review. Used well, it complements data residency with verifiable control during processing. An Architecture & AI Review can clarify which AI workloads need this protection level and how attestation, key management, and operations should work together.