TL;DR: Cloud workloads now carry sensitive data across distributed, multi-cloud environments, where misconfigurations, insider threats, supply-chain exposure, and multi-tenancy leave data in use vulnerable even when data at rest and in transit are protected, according to Anjuna’s guide. The practical shift is from perimeter trust to continuous inventory, least privilege, attestation, and isolation.
At a glance
What this is: This guide explains cloud workload security and argues that confidential computing is needed to protect sensitive data in use, not just at rest or in transit.
Why it matters: It matters because IAM, workload identity, and access governance only reduce risk if the runtime environment itself is trusted before keys and sensitive data are released.
Context
Cloud workloads are the applications, services, and processes that execute on cloud infrastructure, and their security profile changes once sensitive data, third-party dependencies, and ephemeral runtime patterns are part of the design. Traditional perimeter trust breaks down in distributed cloud environments, so the governance problem shifts to inventory, access scope, and runtime trust.
The identity angle is real here because workloads, APIs, and services often authenticate with credentials, roles, and keys that can be over-permissioned or released into untrusted environments. Confidential computing changes the trust boundary by requiring attestation before sensitive material is handed to a workload, which aligns runtime access with identity assurance instead of configuration claims alone.
Key questions
Q: How should teams secure cloud workloads that process sensitive data?
A: Start by combining continuous workload inventory, least privilege, and runtime isolation. If the workload handles regulated or high-value data, require attestation before releasing keys or secrets, and keep monitoring for misconfigurations, exposed ports, and over-permissioned identities.
Q: Why do confidential computing controls matter for cloud workloads?
A: They matter because encryption alone does not protect data while it is being processed in memory. Confidential computing reduces that exposure by isolating the runtime and proving integrity before sensitive material is released into the environment.
Q: What breaks when cloud permissions are broader than the workload needs?
A: Broad cloud permissions allow an attacker to provision miners, expand instances, and hide cost growth inside normal administration activity. When the role can create infrastructure freely, cryptojacking becomes a scaling problem rather than a single-host infection. Least privilege must limit resource creation, not only data access.
Q: When should organisations prioritize attestation over simple environment trust?
A: Prioritise attestation whenever a workload receives sensitive data, credentials, or regulated records and the runtime may be shared, elastic, or provisioned by third parties. In those cases, configuration claims are not enough to justify access.
Technical breakdown
Why data in use is the weak point in cloud workload security
Data at rest and data in transit are the easy parts of the lifecycle to protect because encryption can cover storage and transport relatively cleanly. Data in use is harder, because the workload must decrypt and process information inside memory where the host OS, hypervisor, or another tenant may still be able to observe or interfere. That is why cloud workload security increasingly depends on runtime isolation, not just perimeter or storage controls. Confidential computing narrows the trust boundary by protecting the execution environment itself, which matters whenever workloads process regulated, sensitive, or high-value information.
Practical implication: Treat data-in-use protection as a separate control objective, not an assumption inherited from storage or transport encryption.
How attestation changes workload trust decisions
Attestation is cryptographic proof that a workload is running inside a genuine, expected trusted execution environment and not a spoofed or tampered one. It moves trust from configuration statements to verifiable evidence before keys, secrets, or sensitive data are released. That distinction matters because cloud environments are elastic and can be provisioned quickly, which also makes them easy to misrepresent or misconfigure. For identity practitioners, attestation is the point where workload identity becomes actionable: access is granted only after the runtime proves what it is and where it is executing.
Practical implication: Gate sensitive data release on attestation, especially where workloads access secrets, regulated records, or model inputs.
Why workload identity and least privilege still matter in confidential environments
Confidential computing reduces exposure inside the runtime, but it does not replace identity, authorization, or lifecycle governance. Workloads still need scoped permissions, short-lived credentials, and clear ownership, because a protected execution environment can still be misused if the workload itself is overprivileged. The article’s examples, including APIs, batch jobs, machine learning workloads, and autonomous software apps, all rely on access paths that need explicit governance. This is where NHI and cloud workload identity meet: runtime protection contains damage, while least privilege limits what the workload can reach in the first place.
Practical implication: Combine confidential computing with workload identity controls, credential scoping, and permission reviews for every production workload.
Threat narrative
Attacker objective: The attacker aims to reach sensitive data, abuse runtime access, and expand from one compromised workload into broader cloud exposure.
- Entry occurs when a cloud workload is deployed with misconfigurations, exposed management ports, or default credentials that let an attacker reach the runtime or its data.
- Credential abuse or access misuse follows when overly permissive IAM roles, third-party dependencies, or stolen workload secrets let the attacker operate inside the environment.
- Impact is data exposure, lateral movement, or persistence across workloads, especially where sensitive data is processed in untrusted runtime conditions.
Breaches seen in the wild
- Indian government breach 2021: Sakura Samurai found exposed .git and .env files across Indian government sites, leaking 35 credential pairs, private keys and personal data.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
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
Cloud workload security is now a trust problem, not just a hardening problem. Once sensitive data is processed in elastic, distributed environments, the old assumption that perimeter controls are enough no longer holds. The operational question becomes whether the workload itself can be trusted before it receives keys or regulated data. Practitioners should treat runtime trust as a first-class governance decision, not an implementation detail.
Data-in-use protection is the missing layer in many cloud control models. Encryption at rest and in transit remains necessary, but it does not address the exposure window during active processing. Confidential computing is important here because it reframes the control objective from hiding stored data to constraining who and what can observe memory while the workload is running. That is a distinct governance layer for cloud, IAM, and NHI programmes.
Workload identity and confidential computing are complementary, not interchangeable. A verified runtime without least privilege can still reach too much, while least privilege without verified runtime can still release secrets into an untrusted environment. The stronger model is to bind access decisions to both identity scope and runtime attestation. That is the direction cloud governance is heading for sensitive workloads, especially where service accounts and machine credentials are involved.
Supply-chain and multi-tenant assumptions need to be revisited together. The article’s discussion of third-party dependencies and shared infrastructure reflects a broader shift: trust now depends on what is inside the workload stack as much as what surrounds it. That creates a stronger case for environment isolation, provenance checks, and runtime verification as part of a single governance pattern. Practitioners should re-evaluate whether their current controls assume too much about trusted execution in shared cloud contexts.
Confidential computing is becoming a governance control for regulated processing. As more workloads handle personal, financial, or model-sensitive data, runtime protection becomes a compliance and risk-management issue, not a niche architecture choice. The practical implication is clear: if the workload processes sensitive information, the control stack must prove integrity before disclosure, not after compromise.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: Confidential Computing Guide
What this signals
Confidential workload protection is becoming a policy decision about where data can safely exist in memory. For cloud programmes, that means runtime assurance has to sit alongside IAM, segmentation, and logging rather than after them. Teams that still treat data in use as an implementation detail will keep exposing the gap between encryption policy and actual trust.
Service accounts and automation jobs are part of the control surface, not a separate problem. The more cloud workloads depend on machine credentials, the more important it becomes to verify where those credentials are released and under what conditions. This is where workload identity and confidential computing start to reinforce each other instead of competing for budget.
43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec. That concern extends naturally to cloud workloads that process sensitive data in shared environments, because what is exposed at runtime can be learned, copied, or reused downstream.
For practitioners
- Inventory every sensitive workload Build a continuous inventory of cloud workloads that process regulated data, secrets, or high-value analytics so nothing critical is operating without ownership or review.
- Enforce least privilege for workload identities Review the permissions attached to service accounts, APIs, and automation jobs so each workload receives only the access needed for its current function.
- Require attestation before data release Release keys, secrets, or sensitive records only after the workload proves it is running in a genuine trusted execution environment.
- Isolate high-sensitivity processing paths Place the workloads that handle confidential data into isolated runtime boundaries so host, hypervisor, and tenant exposure is reduced.
- Align policy as code with workload deployment Use automated policy checks to block misconfigured workloads, exposed ports, and default credentials before production rollout.
Key takeaways
- Cloud workload risk is no longer limited to perimeter exposure because sensitive data is increasingly processed in shared, elastic runtimes.
- The central control gap is data in use, where encryption at rest and in transit still leave a live exposure window.
- Attestation, least privilege, and isolation are the controls that change the trust model for sensitive cloud processing.
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 CSA Cloud Controls Matrix, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article centres on access control for cloud workloads and machine credentials. |
| Recommendation — Use IAM controls to scope workload permissions and reduce overexposed cloud access. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes credential misuse and movement across cloud workloads. |
| Recommendation — Map cloud workload abuse to credential access and lateral movement, then hunt for over-permissioned paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Least privilege and permission review are central themes in the guide. |
| Recommendation — Review workload entitlements regularly and remove permissions that exceed the workload's function. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Workloads, APIs, and services must authenticate before sensitive data is released. |
| AC-6 — Least Privilege | The guide explicitly recommends minimum permissions for every workload. | |
| Recommendation — Bind workload authentication to IA-9 and only release data after the service proves its identity. Apply AC-6 to every workload identity and audit for permissions that have accumulated beyond need. | ||
Key terms
- Cloud Workload: A cloud workload is an application, service, function, or process that runs in a cloud environment and uses identity, policy, and runtime behaviour to operate. Unlike a static server, it may scale, move, or terminate quickly, which changes how security controls must observe and govern it.
- 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 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.
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 in the context of modern identity programmes. It helps practitioners connect workload trust, access control, and lifecycle governance across cloud and hybrid environments.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org