TL;DR: Key custody now fails in use, not at rest: Anjuna shows that encryption keys must become plaintext in memory, where attackers and AI-assisted tools can find them across heaps, dumps, runners, hardware and TEEs. The real control is shrinking where keys ever exist in cleartext, not trusting vaults alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Anjuna's blog post: Key custody is most exposed when encryption keys become plaintext in memory, because attackers can now find and extract them across software, hardware and build environments.
Why it matters: This matters because identity and security teams must govern where machine keys appear in cleartext, not just how they are stored, especially where build systems, cloud workloads and confidential computing are involved.
Context
Key custody is the discipline of controlling where cryptographic keys exist, how they are released, and who or what can use them. The failure mode is not usually broken cryptography, but plaintext exposure during use, which turns a storage problem into an access problem. That matters for NHI governance because service processes, build runners, and workloads can all become the place where keys are briefly but fatally exposed.
Traditional vaulting models reduce risk at rest and in transit, but they do not eliminate the moment a key is loaded into memory for use. That gap widens when attackers can search large environments quickly, including runtime memory, crash dumps, and cloud build systems. For practitioners, key custody has become a lifecycle and runtime control issue, not just a storage decision.
The article's examples show that the subject is not a niche cryptography edge case. It is a common operational pattern that becomes more dangerous as search, exploitation, and extraction get cheaper.
Key questions
Q: How do teams reduce plaintext key exposure in memory?
A: Teams reduce plaintext key exposure in memory by avoiding long-lived secrets in application processes, using hardware-backed keystores or HSMs, and loading credentials only for the shortest possible runtime. Memory scrubbing, sealed secret retrieval, and per-request token minting further limit where an API key or private key can be copied from RAM.
Q: Why do vaults still leave encryption keys exposed at runtime?
A: Vaults still leave encryption keys exposed at runtime because an application must decrypt or unwrap them in memory to use them for TLS, file encryption, or signing. The live exposure window is the period when the plaintext key exists in process memory, cache, or a kernel buffer before it is wiped or rotated.
Q: How does attested computing protect sensitive key use?
A: Attested computing protects sensitive key use by proving to a trust service that code is running inside a specific measured hardware or enclave state before secrets are released. That lets key material stay bound to verified runtime conditions, so decrypt, sign, or unwrap operations can be restricted to trusted code paths and attested workloads.
Q: What should teams do first after a key appears in a dump?
A: After a key appears in a dump, teams should treat it as compromised, revoke or disable it, rotate every dependent secret, and search for where it was used. They should also scope the blast radius by checking logs, replacing certificates or tokens, and removing the secret from memory, crash artefacts, and any replicated backups.
Technical breakdown
Why keys in process memory are the main exposure window
A cryptographic key must become plaintext to encrypt, decrypt, sign, or verify. That means the live process, heap, register, cache line, or crash dump becomes the real attack surface, even if the key is protected in a vault or KMS when idle. The security question is not whether the cipher is strong, but how long and where the key remains recoverable while in use. In practice, attackers target the window between retrieval and zeroization, because that is when ordinary software controls are weakest. See the BYOK, HYOK and External Key Management Guide.
Practical implication: Treat memory residency as a key risk metric and minimise the time any key spends in cleartext.
How vaults, build runners and dumps reintroduce secret exposure
A vault does not end risk if the application, runner, or operator workflow pulls the secret into an ordinary runtime and then leaves copies behind in logs, crash files, or ephemeral infrastructure. Build systems are especially sensitive because credentials often sit inside short-lived jobs that are still reachable from a compromised endpoint or session. The result is a chain where the secret is protected at rest in one place, then exposed in a different trust zone when needed. That is why secret sprawl and runtime retrieval remain persistent failure modes.
Practical implication: Reduce secret lifetime in runners and purge dumps, logs, and snapshots that can outlive the job.
Why attested silicon changes the custody model but not the math
Trusted execution environments move key use into measured hardware so the OS, hypervisor, and host memory do not see plaintext. That narrows the remote software attack surface, but it does not solve broken algorithms, weak randomness, or unsafe oracle exposure. It also does not remove physical or bus-level threats that can target attestation roots or memory interposers. The control value is real, but only when the organisation understands what silicon hides and what it leaves untouched.
Practical implication: Use attested execution for high-value key use, then separately govern attestation freshness and query abuse.
Threat narrative
Attacker objective: The attacker wants to turn encrypted or attested systems into systems they can impersonate, decrypt, or trust illegitimately.
- Entry begins when an attacker reaches a runtime, build job, dump, or memory-handling environment where keys must briefly exist in plaintext.
- Credential access follows when the attacker extracts the key from process memory, a crash dump, a build runner, or a hardware path that exposes live state.
- Escalation occurs when the stolen key is reused to decrypt data, forge authentication, or access downstream systems that trust the key.
- Impact is key compromise at scale, because one exposed secret can unlock backups, signing trust, or multiple dependent workloads.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
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
Key custody has become a runtime governance problem, not a storage problem. The article's central point is that encryption succeeds mathematically while operational custody fails at the moment of use. That shifts the control objective from protecting files and vaults to controlling where plaintext appears, how long it exists, and which systems are allowed to observe it. For identity and NHI programmes, that means the governing unit is the credential's live exposure window, not the storage location.
Plaintext exposure window: this is the failure mode the article really describes, and it is broader than key leakage. A key can be perfectly stored yet still be recoverable from process memory, dumps, build runners, or hardware paths as soon as it is loaded for use. The control gap is assumption failure: teams assume encryption-at-rest means protection, when the exploitable moment is actually in memory. Practitioners should redesign policy around that window, not around the vault alone.
AI changes key hunting from specialist work to scalable search. The article is right to frame machine intelligence as the force that lowers the cost of finding exposed keys and turning noisy leaks into usable secrets. That matters because defenders can no longer depend on obscurity, manual triage, or the idea that extraction requires rare expertise. In NHI terms, the most important thing is not whether the key is secret in theory, but whether it is discoverable in practice by automated tooling.
Attested computing narrows the problem, but it does not eliminate the residue. Moving custody and use into a TEE materially reduces what the OS, hypervisor, and co-resident workloads can see, which is why it is a serious architectural response. But the article also shows that physical bus attacks, attestation trust, and malicious oracle use remain live issues. The field should treat TEEs as a custody boundary, not as a universal fix.
Confidential computing now needs the same governance discipline as any other trust root. If attestation keys can be reached and reused, then the mechanism that proves trust becomes part of the attack surface. That means organisations should govern measurement freshness, key provenance, and failure handling with the same seriousness they apply to signing keys and privileged access. The practitioner takeaway is simple: trust roots need lifecycle controls, not just deployment controls.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Read next: OSINT and Reconnaissance Guide
What this signals
Plaintext exposure will become the governance metric that matters. Security teams can no longer judge key risk by vault adoption alone, because the real exposure is the moment a secret becomes usable in memory, on a runner, or in a dump. Programmes that still optimise for storage-centric controls will miss the attack path that tooling now makes easier to find.
Runtime secrecy is now measurable, and the measurement problem is changing. According to the Ultimate Guide to NHIs, 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data. That scale suggests the next control conversation is not whether to centralise secrets, but whether runtime handling, offboarding, and exposure detection can keep pace with that centralisation.
Key custody has a new control surface: the organisation now has to govern discovery of secrets, the lifecycle of live keys, and the trust placed in attested execution. The practical implication is that NHI governance, cloud security, and build security are converging on the same question of where secrets can be found.
For practitioners
- Map every plaintext key exposure point Inventory where signing and encryption keys become cleartext in memory, dumps, runners, containers, and hardware-mediated workflows, then assign an owner to each exposure point.
- Harden build and CI secret handling Use short-lived credentials, isolate runners, and ensure crash dumps, logs, and workspace artifacts cannot retain decryptable material after a job ends.
- Move high-value key use into attested execution For sensitive workloads, require measured execution paths that keep plaintext out of the host OS and hypervisor, then verify attestation freshness before release.
- Separate custody controls from algorithm controls Review whether your key risk is about where plaintext appears, or whether the cipher, mode, or oracle exposure is the real weakness, and treat them as distinct control problems.
Key takeaways
- The article's core warning is that encryption fails operationally when keys become plaintext inside environments attackers can inspect.
- The strongest evidence is the range of exposure points, from memory and dumps to build runners, CPUs and confidential computing trust roots.
- Practitioners need to govern key use as a runtime security problem, with lifecycle controls, attestation discipline and faster rotation when exposure is suspected.
Related NHI Mgmt Group resources: BYOK, HYOK and External Key Management Guide · OSINT and Reconnaissance Guide · Azure Key Vault Contributor escalation 2024 · Attack Surface Management 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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Live key exposure in memory, dumps and runners is a secret leakage problem with runtime consequences. |
| NHI-07 — Long-Lived Secrets | The article shows how long-lived or repeatedly reused keys widen the window for memory-based compromise. | |
| Recommendation — Scan for exposed secrets in memory and artifacts, then revoke and rotate any key that could be recovered. Shorten secret lifetime and rotate credentials that persist across jobs or workloads. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key lifecycle governance depends on authenticator handling, rotation and revocation. |
| SC-39 — Process Isolation | Memory exposure across processes, runners and containers makes process isolation directly relevant. | |
| Recommendation — Enforce credential rotation, revocation and secure handling for authenticators that protect sensitive workloads. Isolate secret-handling processes and reduce opportunities for co-resident memory access. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern is live key theft followed by reuse or disclosure of the captured secret. |
| Recommendation — Hunt for credential-access activity that targets live memory and exfiltrates recovered keys. | ||
Key terms
- Key Custody: Key custody is the ownership and control of cryptographic keys across their lifecycle, including storage, rotation, emergency use, and retirement. Poor custody turns encryption into a weak barrier because any identity with key access can recover data that should have remained protected.
- 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.
- 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.
- Crash Dump: A crash dump is a snapshot of a failing process captured for debugging. In security investigations, it can accidentally preserve sensitive material such as keys or tokens if redaction fails. Because dumps often move through multiple systems, they need the same access control, encryption, and handling discipline as other high-value secrets.
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. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org