TL;DR: Critical security systems still expose keys and plaintext in live memory, so privileged attackers can bypass cryptography by reading what applications handle in RAM, according to Anjuna. Confidential computing shifts the trust boundary below the OS and hypervisor, making memory access and attestation the control point instead of perimeter software.
At a glance
What this is: Anjuna argues that the real attack surface for cryptographic, tokenisation, identity and data-protection systems is live memory, where keys and plaintext can be read by privileged actors.
Why it matters: This matters because IAM, PAM and security architects often secure the wrapper while leaving the runtime trust boundary intact, which means a single privileged compromise can expose the systems that guard sensitive data.
Context
The governance gap is not whether sensitive systems use encryption, tokenisation or key management. The gap is that those protections still depend on live memory and privileged runtime access once the workload is executing, which leaves the operating system, hypervisor and admin path inside the trust model.
That matters for identity and access programmes because the control boundary shifts from who can reach the system to who can read the memory while the system is in use. The article's core claim is that conventional perimeter and software controls do not fully cover guardian workloads, especially when privileged access is already assumed.
Key questions
Q: What breaks when guardian workloads still trust the host operating system?
A: The control model breaks because the host can see the same memory where keys and plaintext live during execution. Once privileged actors can inspect that runtime state, encryption still protects the transport or storage layer, but it no longer protects the active workload. The practical result is that token issuance, signing and decryption can be subverted without breaking the underlying cryptography.
Q: Why does privileged access create so much risk for identity and signing services?
A: These services concentrate trust, so one privileged foothold can expose the material used to mint tokens, sign transactions or decrypt data for many downstream systems. The risk is not just account misuse. It is delegated trust collapse, where access to the guardian service becomes access to the estate that depends on it.
Q: How do organisations know if runtime protection is actually reducing exploit risk?
A: Look for evidence that malicious execution paths are being denied in production, not just detected after the fact. If alerts rise but blocked activity stays flat, the control may be observing attacks without changing outcomes. A working runtime layer changes the number of successful attempts, not only the number of findings.
Q: What should security teams do when a guardian service is compromised?
A: Treat it as a trust-chain incident, not just a server incident. Contain the host, revoke any tokens or signing material that may have been exposed, and assume downstream services may already have accepted forged trust. The key decision is whether the compromise could have altered authentication, signing or decryption outcomes across connected systems.
Technical breakdown
Why live memory becomes the control failure point
Cryptographic protection is strongest before a key is used and weakest when the application unwraps it, loads it into memory and operates on plaintext. At that point, the host operating system, hypervisor and any actor with sufficient privilege can inspect the same address space as the workload. The hardware security module still protects keys at rest, but it does not protect data once the secret is in use. This is why crash dumps, memory scraping and privileged host access remain viable even when the underlying algorithms are sound. See the Cryptographic Key Management Guide.
Practical implication: Treat runtime memory as a governed exposure surface, not an implementation detail.
How confidential computing changes the trust boundary
Confidential computing moves the trust boundary below the OS and hypervisor by running workloads inside hardware-enforced enclaves. The memory is encrypted with keys that are available only to the secure CPU, so the cloud operator, host admin and hypervisor cannot read the protected contents in plaintext. Remote attestation adds assurance that the code running is the code the operator intended, rather than a tampered binary or injected process. The model does not remove the need for identity and access control, but it changes what privileged access can see.
Practical implication: Use hardware-backed isolation for workloads where memory exposure would collapse the protection model.
Why guardian services create outsized blast radius
Guardian services such as identity providers, tokenisation engines, signing services and key management systems are high-value because they are trusted by many downstream systems. If one of them is compromised, the attacker does not just reach one application. They inherit the ability to mint tokens, sign transactions or decrypt data across multiple estates. That creates a concentration risk that resembles a shared identity or privilege tier, except the asset being abused is the runtime secret itself. A protected enclave reduces the chance that one privileged foothold becomes enterprise-wide compromise. See the IAM and Identity Provider Buyer's Guide.
Practical implication: Map these services as blast-radius multipliers and prioritise them for stronger isolation and attestation.
Threat narrative
Attacker objective: The attacker aims to steal or misuse the guardian system's live secrets so they can impersonate trusted services and expand access across protected environments.
- Entry occurs when an attacker gains privileged foothold on the host, whether through a rogue admin path, a compromised service account or a chained exploitation path.
- Credential access follows when the attacker reads keys, tokens or plaintext from memory, crash dumps or live processor state rather than breaking the underlying cryptography.
- Impact occurs when the stolen material is used to forge tokens, read protected data or sign transactions across the environments that trust the guardian service.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
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
Guardian workloads now need a runtime trust model, not just a perimeter control model. The article is right to focus on encryption libraries, tokenisation engines and identity providers because these systems concentrate both trust and privilege. Once they execute, their secrets live in memory and become exposed to the same host-level access paths that traditional security models still tolerate. Practitioners should treat runtime exposure as a first-class governance problem, not an edge case.
Memory is the point where cryptography becomes policy failure. The breach pattern described here is not about weak algorithms, but about where the secrets are handled. When keys are unwrapped, cached or loaded into process space, the security question becomes who can inspect that memory, not whether the key length is strong enough. Key management is necessary, but it is not sufficient when the operating system and administrator remain inside the trust boundary.
Confidential computing is becoming the control plane for high-value trust services. Moving the trust boundary below the hypervisor changes the security question from software hardening to hardware-enforced isolation and attestation. That does not eliminate IAM or PAM requirements, but it does reduce the chance that privileged infrastructure access turns into direct visibility over secrets. For identity and data-security leaders, this is where architecture begins to change the blast radius.
This is a concentration-risk issue as much as a cryptography issue. Identity providers, signing services and tokenisation engines often sit in the middle of many downstream trust chains, which makes their runtime exposure disproportionately dangerous. When one guardian fails, the organisation is not facing a single-system breach. It is facing delegated trust collapse across multiple services, so practitioners should review where that concentration exists and how it is isolated.
The named failure mode is runtime secret exposure, and it is the governance gap the article exposes. The assumption that a protected system stays protected while it is operating no longer holds when privileged attackers can read memory directly. That means the control problem is not only key storage or HSM use, but the entire lifecycle of secrets after they are loaded. Security teams should treat this as a governance boundary failure and not a tooling debate.
Read next: Cryptographic Key Management Guide
What this signals
Runtime secret exposure: the key governance problem is no longer whether secrets are encrypted at rest, but whether they remain protected while applications are using them. That is a different control problem, and it pushes identity and platform teams toward attestation-backed runtime isolation rather than deeper software layering.
Confidential computing changes the operational question for sensitive workloads from 'who can administer the box?' to 'what can the box reveal while the workload is live?'. That shift will matter most where token issuance, signing and decryption are central to downstream trust, because those are the places where one exposed memory region can become many exposed services.
For practitioners, the programme signal is clear: the highest-value trust services should be reviewed as concentrated blast-radius assets. Where a privileged admin or cloud operator can still observe live secrets, the architecture has not yet moved the boundary far enough.
For practitioners
- Inventory guardian systems by blast radius Map every encryption library, tokenisation engine, identity provider, signing service and data-protection SDK that can expose live secrets in memory. Rank them by the number of downstream systems that trust them and by the sensitivity of the data they protect.
- Assume host-level privilege is not a safe boundary Review whether OS administrators, hypervisor operators, cloud operators or service accounts can inspect protected workloads while keys are in use. If they can, the current model still trusts runtime infrastructure with secret material.
- Adopt hardware-backed isolation for crown-jewel workloads Prioritise confidential computing for workloads where a memory dump, crash dump or privileged shell would reveal signing keys, token material or plaintext data. Use attestation to verify what code is actually running before you extend trust.
- Rework incident assumptions around memory exposure Update response playbooks so a compromise of a guardian workload is treated as a likely trust-chain event, not a single-host event. Include token forgery, session abuse and downstream access review as part of containment.
Key takeaways
- The article's core warning is that cryptography does not protect a secret once it is loaded into live memory on a privileged host.
- The breach pattern it highlights is a trust-chain problem, where one compromised guardian service can expose many dependent systems.
- Runtime isolation and attestation matter because they move protection below the OS and hypervisor, where conventional admin access can no longer read the data.
Related NHI Mgmt Group resources: Cryptographic Key Management Guide · Machine Identity, PKI and Certificate Lifecycle Guide · IAM and Identity Provider Buyer's Guide · Workforce Identity Security Guide
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets exposed in memory after they are loaded for use. |
| NHI-05 — Overprivileged NHI | Guardian services become high-risk when privileged hosts can read their secrets at runtime. | |
| NHI-07 — Long-Lived Secrets | The article shows how long-lived signing material becomes dangerous once exposed in runtime memory. | |
| Recommendation — Eliminate memory-exposed secrets where possible and isolate workloads that must handle them. Reduce privilege around guardian workloads so host-level access cannot inspect live secret material. Shorten secret lifetime and rotate any key material that may have been exposed in crashes or dumps. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about how secret material used for authentication and signing must be managed across its lifecycle. |
| Recommendation — Apply authenticator lifecycle controls to rotate and revoke secrets that protect guardian services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The trust problem is whether privileged actors can access live secret-bearing workloads. |
| Recommendation — Review entitlements so host, hypervisor and admin access cannot reach protected runtime state. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attack pattern depends on privileged access to read secrets from memory and then use them to impersonate trusted services. |
| Recommendation — Map memory-reading attack paths to credential access and privilege escalation detections. | ||
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.
- Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
- Remote Attestation: Remote attestation is the process of proving, with cryptographic evidence, that a workload is running inside a specific trusted environment. It matters in AI governance because it replaces a verbal trust claim with checkable proof that the inference session used the intended protected boundary.
- Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
Deepen your knowledge
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 the runtime risks that shape modern security architecture.
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