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.
Expanded Definition
Confidential computing is the practice of processing sensitive data inside a hardware-protected environment so the infrastructure operator cannot inspect it while it is in use. In NHI and IAM contexts, the term usually combines enclave isolation, remote attestation, and controlled execution to create a trust boundary around workloads, not just around stored data.
It is often discussed alongside NIST SP 800-63 Digital Identity Guidelines because the same assurance mindset applies: the system must prove something about its state before sensitive operations are allowed. Definitions vary across vendors, especially around what counts as an enclave, which hardware guarantees are required, and how much the cloud operator can observe. NHI teams should treat confidential computing as a control for reducing exposure, not as a replacement for encryption, access management, or secret hygiene. It is most useful when workloads must process secrets, tokens, or regulated data without exposing plaintext to administrators, hypervisors, or adjacent tenants.
The most common misapplication is treating enclave deployment as automatic protection, which occurs when teams trust the hardware boundary without validating attestation or the application’s secret-handling path.
Examples and Use Cases
Implementing confidential computing rigorously often introduces operational and performance constraints, requiring organisations to weigh stronger in-use data protection against added complexity in deployment, attestation, and debugging.
- Decrypting an API key or signing credential inside an enclave so an AI agent can call downstream services without exposing the secret to the host OS.
- Running fraud detection or risk scoring on regulated customer data in a cloud environment while limiting operator visibility into the raw records.
- Performing key derivation or token exchange for a non-human identity after verifying enclave attestation, rather than handing the workload long-lived credentials.
- Processing data for an AI agent that needs temporary access to sensitive records while keeping the model host and platform operator out of the plaintext path.
- Reducing blast radius in scenarios similar to the JetBrains GitHub plugin token exposure pattern, where a compromised execution environment could otherwise reveal high-value secrets.
For identity-sensitive workloads, confidential computing is strongest when paired with a trusted verification model such as NIST SP 800-63 Digital Identity Guidelines and short-lived credentialing. It is also used in federated workflows where the recipient service must prove its execution state before receiving a token, certificate, or signing material.
Why It Matters in NHI Security
Confidential computing matters because NHIs often carry the credentials, certificates, and API tokens that attackers target after gaining execution or infrastructure access. NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage. That makes in-use protection relevant wherever a service account, agent, or automated workflow must handle sensitive material in a shared environment.
This control is especially important when secrets are used transiently by AI agents, CI/CD jobs, or ephemeral service accounts. Without it, a compromise of the host, orchestration layer, or adjacent workload can expose plaintext data even if storage encryption and vaulting are in place. A confidential computing design should be paired with strong attestation policy, tight secret issuance, and narrow authorization boundaries. It also fits with the operational realities described in the Ultimate Guide to NHIs, where unmanaged identities and secret sprawl create broad exposure paths.
Organisations typically encounter the need for confidential computing only after a workload or token has been exposed during an incident, at which point in-use protection becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | In-use secret exposure is a core NHI risk when workloads handle credentials. |
| NIST SP 800-63 | Identity assurance concepts support trusted release of sensitive material. | |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes no implicit trust in the host handling sensitive data. |
Protect NHI secrets in enclaves and verify attestation before releasing credentials.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
