TL;DR: Confidential computing has evolved from a niche processor feature into an ecosystem spanning CPUs, GPUs and every major cloud, according to Fortanix, while remaining limited by trust assumptions, attestation maturity and provider re-entry into the TCB. The governance shift is from assuming infrastructure to verifying it, and that changes how sensitive workloads should be designed.
At a glance
What this is: This is a retrospective on ten years of confidential computing that argues the model has become mainstream but still carries material trust and implementation gaps.
Why it matters: It matters because confidential computing is increasingly the control that lets identity, workload and data security teams reduce operator trust, verify runtime integrity and protect sensitive processing in cloud and AI environments.
Context
Confidential computing is the practice of protecting data while it is being processed, not only when it is stored or transmitted. The control model matters because many modern services still rely on infrastructure operators, cloud administrators or platform firmware to stay outside the trust boundary by assumption rather than proof.
The article argues that this assumption is no longer enough for sensitive workloads, especially where secrets, model inputs, or regulated data are processed in shared environments. That makes attestation, runtime trust and boundary design central governance questions for teams running confidential computing workloads.
Key questions
Q: How should organisations decide which workloads need confidential computing first?
A: Start with workloads that process regulated data, partner data, or high-value secrets where exposure in memory would create material risk. Prioritise systems that combine sensitive inputs with weak infrastructure trust, such as AI pipelines, multi-party analytics, and services that depend on cloud operators you do not fully control.
Q: Why does attestation matter more than encryption alone for data in use?
A: Encryption keeps memory or data unreadable, but it does not prove that the right code is running. Attestation verifies the workload, firmware and platform state before secrets are released. Without that proof, an encrypted environment can still be the wrong environment, which defeats the point of confidential computing.
Q: What are the signs that a confidential computing deployment still trusts too much?
A: The main warning signs are mandatory provider-managed components, opaque firmware updates, attestation services you cannot inspect and secret release that happens before proof of execution. If the cloud operator can still change the trust chain without meaningful customer visibility, the deployment has not really removed that operator from the risk model.
Q: What is the difference between confidential computing and standard encryption at rest?
A: Encryption at rest protects stored data from offline access, while confidential computing protects data while it is being processed. The difference is the trust problem: encryption at rest assumes the runtime is safe, whereas confidential computing tries to make the runtime itself verifiable before sensitive data is exposed.
Technical breakdown
How confidential computing shifts the trusted computing base
Confidential computing moves the trust boundary from the operating system and cloud operator into hardware-backed isolation. In SGX, the enclave is the smallest boundary, so very little code sits in the trusted computing base. In confidential VMs such as TDX, SEV-SNP and CCA, the boundary expands to the whole guest, which makes adoption easier but increases what must be trusted. The architectural trade-off is simple: broader compatibility usually means a larger trusted base, and stronger isolation usually means more application rework. See the Confidential Computing Guide.
Practical implication: classify each workload by how much of the platform it can afford to trust before selecting an enclave or confidential VM pattern.
Why attestation, not encryption alone, is the control that matters
Encryption protects data from being read, but confidential computing depends on attestation to prove that the workload is what the relying party expects before keys are released. That proof has to cover the platform state, firmware and in some cases attached devices such as GPUs. Without attestation, the environment is just encrypted storage or memory with no trustworthy release condition. The article also shows that provider-controlled attestation services can reintroduce trust in places buyers thought they had removed, which makes the attestation chain itself part of the security design. See the Encryption Guide.
Practical implication: require verifiable attestation and define exactly which parties are still inside your trust chain before releasing secrets.
How confidential GPUs extend the same model to AI inference
Confidential GPU computing extends the protection boundary from CPU memory into AI inference workloads. That matters because prompts, model weights and outputs are often the most sensitive assets in modern AI systems. The article’s key point is that the CPU and GPU each contribute to the trust model, so the deployment inherits two attestation roots and two firmware paths. This is valuable for secure inference, but it also means the security posture depends on how those components are composed and verified together.
Practical implication: treat confidential inference as a composite trust problem and validate both CPU and GPU attestation before handling sensitive prompts or weights.
Threat narrative
Attacker objective: The objective is to access sensitive data in use without relying on a traditional application compromise.
- Entry occurs when a workload runs on shared infrastructure that still leaves the provider, hypervisor or firmware inside the effective trust boundary.
- Privilege or trust escalation happens if secrets are released before attestation is verified, or if provider-controlled components can be changed without customer visibility.
- Impact is unauthorised exposure of sensitive data, prompts or model weights to infrastructure operators, platform administrators or compromised components.
Breaches seen in the wild
- Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Confidential computing is moving from niche isolation to governance baseline: the control is no longer just about protecting secrets inside a processor boundary. It is about deciding which parties remain trustworthy when data is in use, and that shifts the core question from access control to trust verification. Practitioners should now treat runtime confidentiality as a policy decision, not a technical afterthought.
The real control gap is provider re-entry into the trust boundary: many deployments claim to remove the infrastructure operator from the TCB, then add it back through attestation services, firmware, paravisors or mandatory management components. That means the deployment is only as private as its weakest trusted layer. Teams should scrutinise where the provider still sits inside the control plane, not just inside the workload.
Confidential computing exposes a practical identity problem for machine trust: the system must decide when a workload, service or AI inference environment has proved itself enough to receive keys or data. That is a non-human identity question as much as a cryptography question, and it aligns with confidential computing only when attestation is tied to lifecycle-controlled secret release. The practitioner takeaway is to govern machine trust as part of identity design, not as an isolated infrastructure feature.
Secure inference will become the clearest business case for the model: AI concentrates the most sensitive inputs, outputs and weights in the most dynamic workloads. Confidential computing gives security teams a way to reduce exposure without forcing every AI deployment into a bespoke private environment. The result is less reliance on operational trust and more reliance on provable execution, which is where the market is heading.
Confidential computing should now be treated as least privilege for data in use: the article’s long-term trajectory is not feature adoption but expectation change. When the infrastructure operator no longer needs to see the data, the security model becomes materially stronger and the burden shifts to proving platform integrity. Practitioners should plan for that expectation to move from optional control to default architecture.
Read next: Confidential Computing Guide
What this signals
Data-in-use protection is becoming a governance expectation, not a specialist option: the more AI and shared cloud services concentrate sensitive processing, the less acceptable it becomes to rely on operator trust alone. That is why confidential execution is moving from a niche design choice to a broader control pattern for sensitive workloads.
Attestation will matter more than platform branding: buyers will increasingly ask who controls the firmware, paravisor and verification path, not just whether a provider says the environment is confidential. The architecture that survives scrutiny will be the one that can prove what it is running, not the one that merely claims isolation.
Runtime trust is now part of identity governance: when workloads, services and AI systems request secrets based on proof of execution, the governing question is who or what is allowed to become trusted at runtime. That turns machine identity from a static record into a conditional trust decision.
For practitioners
- Define trust boundaries by workload sensitivity Map which applications can tolerate operator visibility and which require confidential execution, then align those workloads to the smallest viable trust base.
- Require attestation before secret release Do not hand over keys, tokens or data until the platform proves the expected code, firmware and hardware state.
- Review provider-controlled components inside the boundary Document any paravisor, attestation service or firmware path the cloud provider can change and decide whether that trust is acceptable.
- Treat confidential inference as a dual-attestation problem For AI workloads using confidential GPUs, validate both CPU and GPU attestation chains before processing prompts or model weights.
- Close off administrative access to confidential workloads Design deployments so operators do not need standing access to the protected data path, then test that secret release still works under that constraint.
Key takeaways
- Confidential computing reduces trust in the infrastructure operator by proving runtime state before sensitive data or secrets are released.
- The article shows that the main governance challenge is not only isolation, but who still sits inside the trust boundary through firmware, attestation and management services.
- For practitioners, the practical test is whether a workload can be verified before data-in-use protection depends on it, especially for AI inference and regulated data processing.
Related NHI Mgmt Group resources: Confidential Computing Guide · Encryption Guide · Google Cloud Security Guide · Google Workspace Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Confidential computing changes who is authorised to see data in use. |
| Recommendation — Apply PR.AA-05 to ensure sensitive workloads only release secrets after verified runtime trust. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret release depends on lifecycle control of credentials and keys. |
| Recommendation — Use IA-5 to govern when keys and secrets are issued to verified confidential workloads. | ||
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | The article focuses on preventing data exposure through trusted runtime abuse. |
| Recommendation — Map confidential computing gaps to credential access and impact paths in your threat models. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Confidential computing relies on identity-bound secret release and trust decisions. |
| Recommendation — Use IAM controls to tie secret release to attested workload identity. | ||
Key terms
- Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
- Trusted Computing: A security model that proves a system is in an expected state before trust is granted. In infrastructure IAM, it extends access decisions beyond identity to include software integrity, attestation, and cryptographic proof of execution context.
- Data in Use Protection: Controls that keep sensitive data confidential while applications are actively processing it. This is distinct from encryption at rest or in transit because the threat model includes runtime operators, hypervisors and other infrastructure layers that can otherwise see plaintext during execution.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to workload trust decisions across modern security programmes.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org