TL;DR: Confidential computing is becoming a CIO priority because it closes the data-in-use gap that traditional controls leave exposed during computation, according to Anjuna, especially for regulated AI, secrets, and multi-party workloads. The governance shift is from perimeter protection to verifiable workload integrity and constrained trust.
At a glance
What this is: Anjuna argues that confidential computing is moving onto the CIO agenda because it protects data while it is being processed, not only at rest or in transit.
Why it matters: For IAM, PAM, and NHI programmes, this matters because privileged infrastructure and cloud trust assumptions no longer fully protect sensitive workloads, keys, or AI processing paths.
Context
Traditional security models have long treated data at rest and data in transit as the main protection points, but data in use has often remained exposed in memory during processing. That gap becomes more important as cloud workloads, regulated analytics, and AI systems handle higher-value data under more distributed operating models.
Confidential computing addresses that gap by isolating workloads inside trusted execution environments so the host operating system, hypervisor, and cloud provider cannot inspect the data while it is being processed. For identity and access teams, the significance is that hardware-enforced trust begins to supplement policy-based trust, especially where workloads carry secrets or sensitive AI inputs.
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 data-in-use risk matter even when data is encrypted at rest?
A: Encryption at rest protects stored data, but it does not stop privileged infrastructure from seeing the data while it is being processed. The risk appears during computation, when memory can expose secrets, records, or model inputs unless the execution environment is isolated and attested.
Q: What are the signs that a workload should move into a confidential computing model?
A: Look for workloads where administrators, cloud operators, or insiders could observe sensitive data during execution, where compliance requires stronger evidence of runtime integrity, or where AI and secrets handling make ordinary cloud trust assumptions too broad. Those are the strongest indicators that the current boundary is too weak.
Q: What should teams do when confidential computing is needed but application rewrites are unrealistic?
A: Choose deployment patterns that allow existing containerised workloads to run inside trusted execution environments without redesigning the application stack. The practical aim is to reduce runtime exposure and strengthen trust evidence without forcing a broad rebuild of the service architecture.
Technical breakdown
How trusted execution environments protect data in use
Trusted execution environments, or TEEs, are hardware-backed isolation zones that protect code and data while they are actively being processed. The key shift is that memory is no longer assumed to be a trusted boundary. Instead, the platform encrypts and isolates the workload so privileged infrastructure layers cannot directly inspect it. That matters because many conventional cloud controls stop at the host OS or hypervisor boundary, which leaves a residual exposure window during execution. In confidential computing, cryptographic attestation proves what code is running before data is released, which turns runtime trust into something verifiable rather than assumed. See the Confidential Computing Guide.
Practical implication: Treat attestation as a prerequisite for sensitive workload access, not an optional assurance step.
Why confidential computing changes AI and secrets governance
AI workloads and key management both concentrate risk because they combine sensitive data, high privilege, and dynamic runtime behaviour. In an AI pipeline, the model may process regulated records, partner data, or proprietary telemetry that should not be visible to the underlying infrastructure. In the same way, secrets and cryptographic keys become more exposed when platform operators or insiders can reach memory. Confidential computing reduces that exposure by keeping secrets inside enclaves and by making workload identity and integrity part of the trust decision. That is why the control is more than encryption at rest with a new label. See the Encryption Guide.
Practical implication: Classify AI systems and secret-bearing services as candidates for enclave-based protection when exposure in memory is unacceptable.
What multi-party collaboration looks like under confidential computing
Multi-party data sharing has traditionally forced organisations to choose between collaboration and visibility. Confidential computing changes the trust model by allowing one party to process another party's data without handing over raw infrastructure access or exposing the underlying dataset to the platform operator. The important technical point is that the assurance comes from hardware isolation plus attestation, not from promises about administrative behaviour. That makes it relevant to regulated sectors where auditability, data residency, and partner trust all matter at once. The trade-off is operational complexity, but the trust boundary becomes materially narrower. See the Privacy-Enhancing Technologies Guide.
Practical implication: Use confidential computing when the collaboration model requires processing shared data without expanding who can see it.
Threat narrative
Attacker objective: The objective is to reach sensitive data in use, including secrets, regulated records, or AI inputs, by exploiting runtime trust assumptions.
- Entry occurs when sensitive workloads, AI pipelines, or shared data processes move into infrastructure where memory exposure would otherwise be possible.
- Escalation happens when privileged host access, cloud operator visibility, or insider control could inspect data during execution rather than only at rest.
- Impact is the compromise of regulated data, cryptographic material, or AI inputs that should never have been exposed to the runtime environment.
Breaches seen in the wild
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
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 becoming a runtime trust control, not just a data protection control. Traditional encryption stops at rest and in transit, but modern AI and regulated workloads create a third exposure point during computation. That means the relevant governance question is no longer whether data is encrypted, but whether the execution environment itself is trustworthy enough to receive sensitive inputs. For identity programmes, this shifts control emphasis toward attested workload identity and constrained runtime access.
The named concept here is the data-in-use trust gap. That gap exists when organisations protect stored and transmitted data but leave processing-time visibility to infrastructure operators, insiders, or platform layers. The article's core point is that this gap becomes structurally harder to accept as AI and multi-party processing grow. Practitioners should treat runtime exposure as a board-level risk, not a technical edge case.
Confidential computing matters most where privileged infrastructure can no longer be assumed trustworthy by default. The article is effectively describing a narrower trust perimeter for cloud and AI operations, which is especially relevant when secrets, regulated records, or partner data must be processed under audit pressure. That intersects directly with NHI governance because the identities most likely to touch these workflows are service accounts, workload identities, and automation paths. Confidential computing is therefore part of a broader shift from perimeter trust to execution trust.
This also changes how assurance is argued to regulators and auditors. A tamper-proof statement about workload integrity is more defensible than a general claim that the environment is secure, because it can be tied to attestation and policy enforcement. For compliance-heavy teams, that narrows the evidence gap between architecture and control validation. The practical conclusion is that assurance now has to extend into runtime, not stop at deployment.
Confidential computing will not replace IAM, but it will change where identity control has the strongest leverage. When the most sensitive trust decision moves to the enclave boundary, identity teams need to think about who can release keys, approve attestation, and define workload trust policy. That makes the control plane around the enclave as important as the enclave itself. Practitioners should align workload identity, key release, and privilege policy before scaling confidential workloads.
Read next: Confidential Computing Guide
What this signals
Runtime trust will become a design assumption for more AI and data programmes. As sensitive workloads move deeper into cloud and agentic processing models, the old split between encrypted storage and trusted execution will become harder to defend. Teams that do not redesign around workload attestation will keep inheriting trust from infrastructure they cannot actually verify.
Confidential computing is also a control-plane problem, not just a hardware feature. The enclave matters, but the real governance question is who can release keys, approve attestation, and define what trusted execution means for each workload class. That makes identity policy, workload identity, and key custody part of the same security decision.
Data-in-use protection will increasingly sit alongside NHI governance for sensitive automation. Where AI systems, service accounts, or partner workflows handle regulated data, the trust model has to extend beyond access grants to execution integrity. That is why confidential computing belongs in programme planning now, before agentic systems expand the blast radius of a compromise.
For practitioners
- Define enclave-worthy workloads Prioritise AI, secrets-bearing, and regulated-data workloads that cannot tolerate exposure during processing. Start with systems where infrastructure visibility would create unacceptable compliance or confidentiality risk.
- Bind key release to attestation Require cryptographic attestation before secrets or keys are released into the workload environment. This prevents infrastructure layers from seeing protected material before the runtime is proven trustworthy.
- Inventory workload identity paths Map which service accounts, automation jobs, and workload identities can reach sensitive data flows. Focus on the identities that can launch, approve, or connect to confidential compute environments.
- Create an assurance case for regulators Document how attestation, workload isolation, and key custody together provide evidence that sensitive data was protected during execution, not only in storage and transit.
Key takeaways
- Confidential computing addresses a real gap in conventional encryption by protecting data while it is being processed, not only when stored or transmitted.
- The article's central evidence is that AI, regulated analytics, secrets handling, and multi-party collaboration all raise the cost of leaving runtime trust implicit.
- Practitioners should start with workloads that need attestation, key release control, and stronger evidence of execution integrity before scaling the model.
Related NHI Mgmt Group resources: Confidential Computing Guide · Encryption Guide · Attack Surface Management Guide · Kubeflow cryptomining attacks 2020
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article ties confidential computing to secrets and workload trust, which depends on stronger runtime authentication boundaries. |
| Recommendation — Use NHI-04 to require stronger trust proof before sensitive workload credentials are released. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Confidential computing changes who can access sensitive data during execution, not just at rest. |
| Recommendation — Apply PR.AA-05 to tighten access permissions around sensitive runtime environments and key release decisions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article explicitly discusses secrets and key management inside hardware enclaves. |
| Recommendation — Use IA-5 to govern the lifecycle and release of credentials used by sensitive workloads. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat model includes adversaries trying to reach secrets and sensitive data through runtime exposure. |
| Recommendation — Map runtime exposure paths to TA0006 and monitor where credentials or keys could be harvested in memory. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud workload trust and key release are central to the article's confidential computing use cases. |
| Recommendation — Apply IAM controls to govern who can authorise and release access into confidential workloads. | ||
Key terms
- Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
- Data In Use: Data in use is information being actively accessed, processed, or modified by a user, application, or workload. It is the hardest state to govern because policy must follow live identity behaviour, not just storage location or network transit.
- Cryptographic Attestation: Cryptographic attestation is a method of proving that a workload or service is genuine by using cryptographic evidence instead of static shared secrets. It is especially useful for short-lived access models because identity proof is tied to runtime context rather than reusable credentials.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suitable for practitioners who need to connect workload identity and governance to broader security decisions.
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