The Third State of Data Security: Confidential Computing for AI—Protecting Data-in-Use with TEEs on AWS, Azure, and Google Cloud
Why “Data-in-Use” Is the New Frontier
Organizations have learned to encrypt data at rest and in transit. Yet the moment data is decrypted to be processed—especially by AI models—it becomes exposed to the operating system, hypervisor, and anyone with privileged access to the underlying infrastructure. That gap is exactly where confidential computing operates. It protects data-in-use inside a trusted execution environment (TEE), using hardware-enforced isolation and attestation to prove to a remote party that code is running in a secure, measured context. For AI workloads that frequently combine sensitive first-party information with valuable proprietary models, TEEs create a practical way to compute on secrets without exposing them to the rest of the platform.
This “third state” is moving from niche to mainstream, with the three major clouds providing TEE-backed services and instance families. The payoff isn’t hypothetical: financial institutions are conducting fraud analytics on regulated data; healthcare systems are running privacy-preserving inference over protected health information (PHI); and AI vendors are delivering models as a service without disclosing their parameters to customers—or, critically, to the cloud operator.
The Threat Model: Why AI Raises the Stakes
AI accelerates both value creation and risk. Models ingest sensitive signals, produce outputs that may encode secrets, and often run at scale on shared hardware. Threats include:
- Privileged insider risk: Administrators or cloud operators with root or hypervisor-level access traditionally had visibility into memory contents.
- Malicious co-tenants: Side-channel attacks attempt to infer information across boundaries in multitenant environments.
- Supply-chain tampering: Untrusted binaries, compromised images, or runtime hooks can exfiltrate model weights or training data.
- Key escrow or misuse: If cryptographic material for decrypting data or models is accessible outside a TEE, a compromise can cascade.
AI compounds these concerns because inference requires plaintext access to both inputs and model parameters. Without data-in-use protections, any guarantee of encrypted storage and TLS becomes moot during compute. Confidential computing shifts trust from administrators and software layers to measured hardware and attestation-based policies.
Confidential Computing, Explained
Confidential computing uses CPU and accelerator capabilities to create TEEs—environments where memory is encrypted, integrity-checked, and isolated from the host OS, hypervisor, and other VMs. Remote attestation produces a signed statement about the identity and state of the TEE (e.g., processor keys, microcode level, boot measurements, loaded image), enabling a relying party to decide whether to release secrets or interact with the workload.
Two Major Flavors of TEEs
- Process-level TEEs (e.g., Intel SGX): Fine-grained enclaves embedded in a process. Strong isolation, limited memory, specialized programming model. Useful for protecting small secrets or libraries.
- VM-level TEEs (e.g., AMD SEV-SNP, Intel TDX, AWS Nitro Enclaves): The entire virtual machine or an enclave VM is protected, supporting larger memory footprints and more transparent integration with containers and orchestration. This is where most cloud AI patterns are converging.
Remote Attestation, in Practice
Attestation allows a key manager or data owner to check a measurement of the workload before releasing keys or data. The flow typically looks like:
- The TEE produces an attestation report signed by hardware-backed keys.
- A verifier (cloud attestation service, independent policy engine, or a key broker) validates the report and checks policies: allowed image hashes, permitted regions, expected kernel versions, and runtime parameters.
- If policy passes, the verifier authorizes decryption of model weights, customer data, or API credentials—often directly sealed to the TEE so secrets never appear outside it.
The result: data owners and regulators can rely on objective evidence of execution integrity rather than trust in administrators.
Confidential Computing on the Big Three Clouds
AWS: Nitro Enclaves and Attestation-Driven Key Release
AWS builds on the Nitro System, a minimal, hardened hypervisor and dedicated offload hardware. Nitro Enclaves carve out isolated memory and vCPUs from an EC2 instance, creating an enclave VM with no persistent storage, no direct networking, and no interactive login. Communication occurs over vsock, and secrets generally flow in only after attestation and policy checks.
- Attestation and keys: Nitro Enclaves integrate with AWS KMS so that decryption is conditioned on an enclave attestation document. AWS Certificate Manager for Nitro Enclaves can keep private TLS keys exclusively inside the enclave.
- Developer model: You run an application on the parent instance, forward requests to the enclave via vsock, and use the Nitro Enclaves SDK to verify attestation documents and call KMS.
- AI pattern: Keep proprietary model weights encrypted at rest (S3 with SSE-KMS). On boot, the enclave presents its attestation to KMS, which releases the key to decrypt model weights inside the enclave. Clients send inputs to the parent instance, which forwards to the enclave for inference. The model and inputs never appear in plaintext outside the TEE.
Real-world example: A fintech runs a “private inference API” for credit risk scoring. The vendor’s proprietary model is protected from customers and cloud admins; customer financial attributes remain confidential. The enclave exposes only scoring results, with audit logs sealed inside and periodically pushed out after encryption.
Azure: Confidential VMs, Attestation, and Confidential Containers
Azure offers VM families with both AMD SEV-SNP and Intel TDX, bringing memory encryption and integrity verification to the entire guest VM. Microsoft Azure Attestation (MAA) provides verification and policy evaluation, and Azure Key Vault or Managed HSM can be configured for attestation-gated key release. Azure Kubernetes Service (AKS) supports confidential node pools and confidential containers to run containerized workloads in TEEs with minimal refactoring.
- Confidential VMs: DCasv5/ECasv5 (AMD SEV-SNP) and DCesv5/ECesv5 (Intel TDX) families support broad software stacks. Measured boot and SNP/TDX reports are usable in MAA policies.
- Attestation policy: MAA evaluates evidence such as TEE type, firmware versions, and image measurements. Only if the deployment matches the policy does Key Vault permit key release.
- AI pattern: A healthcare provider launches a confidential AKS node pool. An inference service runs as a confidential container; the node attests to MAA. Key Vault releases the model decryption key only when the expected image digest is running on a verified confidential node in the approved region. PHI arrives over TLS and is processed entirely within the TEE-backed node.
Real-world example: A hospital system performs entity recognition on clinical notes to drive care coordination. Because both the inputs (PHI) and the model (licensed NLP) are sensitive, the architecture relies on AKS confidential nodes, MAA policies pinned to image hashes, and Key Vault with role separation between operators and key administrators.
Google Cloud: Confidential VMs, Confidential GKE Nodes, and Confidential Space
Google Cloud’s Confidential VMs use AMD SEV and SEV-SNP to protect VM memory, offering compatibility with existing OS images and container platforms. Confidential GKE Nodes bring similar protections to Kubernetes clusters. Confidential Space extends the model with an attested runtime designed for collaboration and data sharing scenarios where multiple parties require assurance before releasing data or keys.
- Confidential VMs: Compute Engine instances with memory encryption and integrity protection, compatible with common Linux distributions and toolchains.
- Confidential GKE Nodes: Run containerized workloads on nodes with TEE protections; integrate with admission controls and workload identity.
- Confidential Space: An attestation-first service for multiparty computing and key release flows. It’s useful when data providers and model owners are separate entities.
Real-world example: An ad-tech consortium executes privacy-preserving audience matching. Brand identifiers are encrypted and released only to an attested Confidential Space workload with a verified image digest. The matching algorithm runs, outputs aggregated insights, and the raw inputs never leave TEE memory.
Accelerators and GPUs: The Emerging Frontier
GPUs are becoming TEE-aware. Modern accelerators are adding hardware features to protect device memory, secure firmware, and enable attestation. Early offerings allow “confidential GPU” modes that restrict device introspection and enforce encrypted memory on the accelerator. Availability and capabilities vary by cloud and region, and the ecosystem is still maturing. The direction is clear: as AI scales, accelerators will offer attestation and encrypted memory to extend data-in-use protections beyond the CPU.
Architectural Patterns for AI With TEEs
Private Model Inference
This pattern protects both inputs and model weights. It’s common for ISVs selling high-value models or enterprises applying sensitive features to PII.
- Encrypt model weights with a key stored in a cloud KMS or HSM.
- Deploy an enclave-based service (Nitro Enclave, Confidential VM, or confidential container) with a minimal, auditable runtime.
- Perform remote attestation against the cloud attestation service and a policy engine.
- On successful attestation, release the decryption key to the TEE. Load and serve the model entirely inside the enclave.
- Send inputs via an authenticated proxy; ensure payloads are decrypted only inside the TEE. Return only necessary outputs.
Use cases include risk scoring, medical imaging triage, and code-assist models that must protect proprietary weights from customer access.
Training on Sensitive Data
Training within TEEs is possible but requires forethought due to memory, I/O, and observability constraints. A practical approach is staged:
- Preprocessing in TEEs: Tokenization, filtering, or de-identification runs in a TEE; the anonymized data can then be used on standard infrastructure if policy allows.
- Epoch-by-epoch key release: Only a small shard of training data is decrypted at a time inside the TEE to bound exposure.
- Federated learning with TEE aggregator: Participants train locally; encrypted updates are sent to an attested aggregator running in a TEE. The aggregator decrypts updates only after verifying attestation, computes the new global model, and discards raw updates.
Where GPU TEEs are available, end-to-end confidential training becomes more feasible, but today many teams combine CPU TEEs for sensitive steps with standard accelerators for heavy math while managing the risk appetite.
Confidential Feature Stores and Retrieval-Augmented Generation (RAG)
Feature computation often contains business-sensitive logic and raw PII. By computing features or embeddings in a TEE and storing only the derived artifacts, you reduce risk while keeping performance. For RAG, a TEE can ingest a private corpus, build an index, and serve embeddings and retrieval within the enclave, ensuring that proprietary documents and chunked vectors are never exposed in memory outside the TEE.
Multi-Party Collaboration
Confidential computing enables “clean rooms” where multiple data owners contribute encrypted data to a jointly attested workload. Each participant verifies the measurement, policies, and region before releasing keys. Only aggregated outputs exit. This pattern is used in financial consortium analytics, health research cohorts, and cross-brand marketing measurement.
Cross-Cloud and Portability
To keep options open across AWS, Azure, and Google Cloud, design for VM-level TEEs and abstract attestation. A common pattern is to build a Key Broker Service (KBS) that consumes cloud-specific attestation evidence and implements a unified policy language. Workloads can then move between SEV-SNP, Intel TDX, and Nitro Enclaves with minimal change in application logic, while the KBS translates the attestation format and verifies measurements.
Attestation and Key Management: From Theory to Operation
The Key Broker Service Pattern
A KBS decouples attestation verification from cryptographic key custody and application logic:
- The workload requests a secret from the KBS, presenting its hardware attestation report.
- The KBS verifies the report against trust anchors (e.g., AMD/Intel endorsements, cloud attestation service) and evaluates policies: image digest, allowed regions, workload identity, environment variables, and configuration.
- If approved, the KBS instructs a KMS/HSM to wrap or release the key bound to the TEE’s identity, returning it over a mutually authenticated channel.
This architecture centralizes policy and audit while keeping secrets gated by verifiable evidence. It is also how you support multi-cloud attestation with a consistent interface.
Policy as Code for TEEs
Treat attestation policies like code: version them, review changes, and roll them out with CI/CD. Policies commonly include:
- Hardware baselines: Minimum microcode/firmware versions, TEE type (SNP vs TDX vs Nitro).
- Image measurements: Container image digests, OS image IDs, SBOM signatures.
- Runtime constraints: Region, instance family, vCPU/memory bounds, environment variables.
- Identity bindings: SPIFFE IDs or workload identities mapped to specific roles and key material.
Supply Chain Integrity
Attestation is only as strong as the software you measure. Combine it with supply-chain controls:
- Signed artifacts: Use Sigstore/cosign to sign images; verify signatures inside CI and at admission time.
- SBOMs and policies: Generate SBOMs (e.g., SPDX) and use policy engines to block disallowed components.
- Reproducible builds and SLSA levels: Harden build pipelines to mitigate tampering.
The goal is end-to-end traceability: code provenance feeds into image signatures that feed into attestation policy, enabling automatic key release only for trustworthy binaries.
Identity and Access for Workloads
Map TEE-attested identities to cloud-native authorization. Examples include:
- Short-lived tokens: Issue tokens after attestation that allow scoped access to storage or messaging.
- SPIFFE/SPIRE: Assign a SPIFFE ID to the enclave and use it in mutual TLS with upstream services.
- KMS conditions: Require attestation claims in the key policy, not just IAM role membership.
This keeps secrets flow tightly coupled to measured execution, not human-managed long-lived credentials.
Performance, Cost, and Developer Experience
Overhead and Capacity
VM-level TEEs typically add modest overhead. Memory encryption and integrity checks can reduce throughput by single-digit percentages in many workloads, though cryptography-heavy or I/O-bound pipelines may see more. Nitro Enclaves trade networking convenience for isolation; all I/O is proxied via vsock. SEV-SNP and TDX VMs operate much like standard VMs but can impose constraints on live migration, debugging, or performance counters.
Capacity planning matters: enclave memory is dedicated and cannot be oversubscribed. For AI inference, this means sizing enclaves to hold model weights plus working memory. For training, memory pressure can be significant; consider sharding models, parameter-efficient fine-tuning, or staged decryption to limit the in-TEE footprint.
Developer Ergonomics
Debugging inside a TEE is intentionally constrained. You will rely more on:
- Structured logging: Buffer and encrypt logs inside the TEE; export them after sealing to a key only the TEE can use.
- Deterministic builds: Reproduce image digests quickly to recover from a broken rollout.
- Emulation and “unenclaved” modes: Develop locally, then promote to a TEE with minimal code changes, validating that the attestation policy and key-release path function as expected.
Cost Considerations
Confidential instances may carry a premium, and operational overhead for attestation, policy, and KBS management is real. However, offsetting factors include reduced data-masking complexity, faster legal and compliance approvals for sensitive workloads, and the ability to unlock high-value data collaborations that were previously blocked due to risk.
Security Pitfalls and How to Avoid Them
Side Channels and Metadata Leaks
TEEs mitigate many classes of attacks but do not eliminate side channels. Timing, cache effects, page-fault patterns, and output channels can reveal information. Mitigate by:
- Constant-time, side-channel-resistant crypto libraries.
- Noise injection or batching to reduce correlation between requests and outputs.
- Careful control of logging and error messages to avoid leaking sensitive metadata.
I/O Boundaries
Protect the boundaries between the TEE and the outside world. Use authenticated encryption for data crossing vsock or virtio channels. Validate and sanitize inputs in the TEE; never assume the host environment is honest. For enclaves that rely on host-provided time or randomness, provision enclave-native entropy sources or attested time services.
Key Lifecycle and Sealing
Ensure keys are sealed to TEE measurements or identities so that even if exfiltrated, they are useless elsewhere. Rotate keys and update policies regularly. For long-running services, design a re-attestation flow to renew trust and enforce upgrades (e.g., disallow outdated microcode after a grace period).
Model Output Controls
For AI, consider the information content of outputs. Add controls to prevent inversion or extraction attacks. Rate-limit, watermark, or clip outputs where applicable, even when inference is protected, because a compromised client could still try to learn about the model or training data indirectly.
Compliance and Governance
Mapping TEEs to Regulatory Requirements
While many regulations emphasize encryption at rest and in transit, data-in-use controls are increasingly referenced in security frameworks and vendor risk assessments. TEEs help with:
- HIPAA: Reducing the number of systems exposed to PHI; demonstrating strong isolation and auditable key release for workloads handling PHI.
- PCI DSS: Protecting cryptographic operations and cardholder data during processing; enforcing least privilege and separation of duties.
- GDPR: Supporting privacy-by-design with minimized exposure and technical measures that restrict access to personal data during compute.
TEEs also support data residency and sovereignty strategies: enforce policies that only attest to and release keys in specified regions and instance families. Combined with audit trails from attestation and KMS events, this provides a defensible narrative for auditors and customers.
Shared Responsibility, Revisited
Confidential computing rebalances trust. Cloud providers deliver TEE capabilities and attestation infrastructure; customers own policies, supply chain integrity, and application-level privacy controls. Document who defines attestation policy, who approves key release criteria, and how incident response incorporates attestation revocation or key invalidation.
Ecosystem and Tooling for Builders
SDKs and Runtimes
- Open Enclave SDK: A cross-TEE abstraction that targets multiple backends and simplifies attestation and sealing.
- Gramine and SCONE: Lift-and-shift runtimes that run unmodified Linux applications inside TEEs with minimal changes, useful for complex dependencies.
- Enarx: A WebAssembly-first approach to deploying confidential workloads across different TEEs.
- AWS Nitro Enclaves SDK: Libraries and examples for vsock communication, attestation document parsing, and KMS integration.
- Azure Attestation SDK and confidential containers capabilities in AKS: Integrations for MAA and policy-bound key release with Key Vault or Managed HSM.
These tools reduce friction, but production systems still need CI/CD pipelines that sign artifacts, verify SBOMs, and embed attestation expectations into deployment manifests.
ML Frameworks and Patterns
Most teams run familiar ML frameworks like PyTorch or TensorFlow inside VM-level TEEs or confidential containers without major code changes. Key considerations:
- Deterministic builds: Pin versions and produce reproducible images to keep measurements stable across environments.
- Model encryption: Store encrypted checkpoints; decrypt inside the TEE on startup.
- I/O shimming: Replace network calls with host-mediated vsock channels in enclave scenarios; ensure integrity and authenticity on every hop.
Homomorphic encryption and secure multiparty computation remain complementary options for specific privacy-preserving tasks, but for general-purpose AI pipelines, TEEs typically deliver far better performance while meeting risk and regulatory constraints.
Deep Dive: Example Architectures on Each Cloud
AWS Private Inference with Nitro Enclaves
Components:
- Parent EC2 instance on a Nitro-based family with sufficient memory for the enclave.
- Nitro Enclave carved with dedicated memory and vCPUs; no network or persistent disk.
- A REST gateway on the parent instance terminates TLS; it forwards sanitized requests over vsock to the enclave.
- Inside the enclave: a minimal runtime, the inference server, and the Nitro attestation/KMS client.
- On boot: the enclave requests decryption of model weights. KMS verifies the attestation document and releases the key if policy passes.
Observability: logs are buffered, encrypted with a TEE-sealed key, and flushed to CloudWatch via the parent instance. Incident response includes invalidating the attestation policy or key aliases to quarantine a misbehaving deployment.
Azure Confidential AKS for Healthcare NLP
Components:
- AKS cluster with a confidential node pool using SEV-SNP or TDX-backed VMs.
- Microsoft Azure Attestation configured with a policy referencing the OCI image digest and node TEE type.
- Azure Key Vault (or Managed HSM) stores model and data decryption keys with conditional release based on attestation claims.
- Ingress controller routes PHI-bearing requests to the confidential deployment. Workload identity avoids static secrets.
Data handling: clinical notes are decrypted only within the confidential pod. Outputs are de-identified summaries. Governance: policies pin processing to specific regions; audit logs tie each key release to a verified attestation report and patient consent event.
Google Cloud Confidential Space for Multiparty Analytics
Components:
- A Confidential Space environment hosting the aggregation service.
- Data owners verify the attestation measurement via a shared policy before uploading encrypted datasets and sharing decryption material.
- The service decrypts inputs, computes cross-party joins or aggregations, and outputs only k-anonymized metrics.
- Cloud KMS with access justifications and customer-managed keys limits key use to approved purposes, aligned with attestation events.
This pattern lets independent organizations collaborate without exposing raw datasets to each other or to the cloud operator, unlocking analyses that satisfy both business goals and privacy constraints.
Data Handling Patterns Unique to AI
Protecting Model Intellectual Property
High-value models are themselves trade secrets. Strategies include:
- Encrypting checkpoints and weights, with decryption allowed only after attestation.
- Removing host observability that might leak parameters, such as ptrace or kernel performance counters.
- Output gating: limit introspective APIs (e.g., weight dumps, debug endpoints) and apply rate limits to resist extraction.
- Watermarking outputs or using provenance signals to trace misuse without weakening confidentiality.
Safeguarding Prompts and Context
In generative AI, prompts, RAG context, and system instructions often contain secrets. Place the entire prompt assembly path inside a TEE. Ensure that vector store access tokens are released only to attested runtimes. Seal per-tenant policies and templates to prevent cross-tenant leakage.
Encrypted Evaluation and A/B Testing
Run offline evaluations in a TEE to keep ground-truth labels protected. Evaluation datasets are decrypted only inside the enclave; metrics and aggregated confusion matrices exit. This allows rigorous model governance without exposing sensitive labels to analysts or operators.
Implementing a Pilot: A Practical Sequence
1) Pick a Narrow, High-Value Use Case
Start with inference over sensitive inputs and a high-value model: fraud scoring, PHI entity extraction, or sensitive document classification. The smaller the scope, the easier it is to validate performance and policy design.
2) Choose a Cloud-Native TEE
On AWS, prefer Nitro Enclaves for strong isolation and attestation-integrated key release. On Azure, use confidential AKS or confidential VMs with MAA policies. On Google Cloud, consider Confidential VMs or Confidential Space for multiparty scenarios. Select instance types with enough memory to hold your model and batch size.
3) Establish Supply Chain and Policy Baselines
Create a hardened base image, sign it, produce an SBOM, and pin the resulting digest in your attestation policy. Define allowed regions and TEE types, and incorporate microcode minimums. Add policy tests to CI so every build produces a measurement you can deploy with minimal policy churn.
4) Build the Key Release Path
Integrate with the cloud’s attestation service and KMS. If you need multi-cloud flexibility, implement a Key Broker Service to centralize policy enforcement and auditing. Ensure that the released key is wrapped to the TEE’s identity and never leaves the enclave in plaintext.
5) Refactor Minimal Application Code
Wrap model loading and decryption in a small, auditable component. Replace filesystem or network paths with enclave-friendly I/O. Add health checks, encrypted logging, and metrics that avoid sensitive content.
6) Test Failure and Rotation Scenarios
Revoke policies, rotate keys, and simulate region failover. Verify that the service fails closed: no plaintext model or data appears, and keys are not released to unexpected measurements. Confirm that rollbacks are possible by preserving a known-good measured image.
7) Measure Performance and Cost
Benchmark tail latency and throughput. Tune batch sizes and thread counts within enclave memory constraints. Compare costs against the alternative (extensive de-identification, isolated dedicated hosts, or foregone collaboration) to quantify ROI.
8) Extend to Additional Pipelines
Once inference is stable, move earlier in the pipeline: feature engineering, embedding generation, or RAG indexing inside TEEs. For collaborations, add a second data provider and enforce per-party policies in the KBS.
Design Checklists
Security and Privacy
- Threat model covers administrators, co-tenants, and supply-chain tampering.
- Attestation policy is versioned, tested, and includes image digests and region restrictions.
- Key release requires attestation; keys are sealed to TEE identity and rotated regularly.
- Logs are encrypted; no sensitive data is written outside TEEs.
- Outputs are constrained to prevent extraction or inversion attacks.
Reliability and Operations
- Automated build pipeline produces signed images and SBOMs.
- Observability does not rely on privileged host introspection.
- Runbooks exist for attestation failures, firmware updates, and region outages.
- Performance baselines reflect enclave memory and I/O limits.
Compliance and Governance
- Policies enforce residency and TEE type; audits correlate key releases with attestations.
- Data retention and deletion occur inside the TEE where needed.
- Access is least-privilege with short-lived credentials post-attestation.
Common Questions Teams Work Through (Without Calling Them FAQs)
Do we need to modify our model code?
Often less than you think. For VM-level TEEs and confidential containers, you can run existing frameworks. The main changes are around key retrieval, sealed storage, and I/O. For enclaves without direct networking (e.g., Nitro Enclaves), you add a small proxy on the parent instance and vsock communication.
What about GPUs?
Confidential GPU capabilities are emerging. Where available, you can extend data-in-use protections to accelerator memory and use attestation to gate access. If not available in your region/instance family, combine CPU TEEs for sensitive steps with standard GPUs, and apply policy and operational controls to manage residual risk.
Will side channels break our guarantees?
Side channels can never be eliminated entirely, but practical mitigations—constant-time crypto, batching, noise, constrained outputs, and strict logging— materially reduce risk. TEEs remove large attack surfaces (host OS, hypervisor) and make remaining avenues costlier.
Can we use homomorphic encryption instead?
HE is powerful for specific computations but remains orders of magnitude slower for general AI workloads. Many teams use TEEs now and monitor HE/MPC advances for future augmentation, particularly for simple aggregations or private set intersections that fit HE-friendly patterns.
A Mental Model for Deciding Where TEEs Fit
When They Are a Strong Fit
- Inference over high-sensitivity inputs (PHI, financial data) and valuable proprietary models.
- Cross-organization analytics requiring verifiable isolation and policy-gated key release.
- Regulated environments where technical controls for data-in-use reduce legal and audit friction.
When to Reconsider or Combine Approaches
- Hyper-scale training where GPU TEE support is unavailable and data is already aggressively de-identified.
- Workloads dominated by public or low-sensitivity data, where cost and complexity outweigh gains.
- Use cases better served by client-side encryption or local/on-prem compute due to latency or data gravity.
Bringing It Together Across AWS, Azure, and Google Cloud
Unified Principles
- Attestation-first: Nothing decrypts until the workload proves what it is, where it runs, and that it matches a policy under your control.
- Separation of duties: Operators deploy; security controls policy; KMS enforces; no single role can bypass attestation.
- Minimal trusted computing base: Ship slim runtimes, verify supply chain, and keep secrets inside the TEE.
- Measured operations: Treat attestation and key-release logs as first-class audit artifacts.
Cloud-Specific Highlights
- AWS Nitro Enclaves: Maximum isolation with vsock comms, tight KMS integration, and certificate handling via ACM for Nitro Enclaves.
- Azure Confidential VMs and AKS: Full-featured confidential containers with Microsoft Azure Attestation and conditional Key Vault release, good for Kubernetes-native teams.
- Google Cloud Confidential VMs and Confidential Space: Memory-protected compute with an attested collaboration service for multiparty scenarios.
For portability, implement a KBS that accepts Nitro, SEV-SNP, and TDX evidence, verify via cloud attestation services, and author a single policy language for your organization. Keep model encryption, image signing, and SBOM generation cloud-agnostic. With that foundation, you can select the best-fit confidential instance in each provider while maintaining a consistent security posture for AI workloads.