Non-Human Identities: Cloud Forensics' Newest Blind Spot
16.07.2026 cloud-forensiknon-human-identityservice-accountsapi-security
For years, security teams focused on human logins, MFA bypasses, and stolen session cookies. But the center of gravity has shifted: machine identities—service accounts, API keys, OAuth tokens, CI/CD credentials, and increasingly AI agents—have become the most common and least monitored attack surface in cloud environments.
A Case Study: How a CI/CD Token Became a Weapon
Google’s recent Cloud Threat Horizons report documents a case involving the North Korean group UNC4899 that makes the scale of the problem tangible. In the next stages, UNC4899 pivoted to the cloud environment and carried out reconnaissance activities, which included exploring specific pods in the Kubernetes cluster, established persistence, and obtained a token for a high-privileged CI/CD service account. This allowed them to move laterally to more sensitive systems, such as a pod responsible for enforcing network policies that allowed them to break out of the container and plant a backdoor. From there, the attacker moved to a system that handled customer information (identities, account security, cryptocurrency wallet data) and hosted database credentials stored insecurely.
What stands out forensically is the technique itself: forensic analysis suggests this access was achieved without necessarily executing a kernel exploit, and instead, UNC4899 mimicked the impact of a host-level escape by abusing cluster admin privileges to probe node-level services. The actors leveraged this access to deploy a backdoor for persistent access and to work around the service account token’s expiration window. No exploit alarm, no malware signature hit—just a stolen token doing exactly what it was designed to do: authenticate.
Why the Evidence Trail Looks Different for Machine Identities
Recent numbers illustrate the scale of exposure: SpyCloud recaptured 18.1 million exposed API keys and tokens in 2025, spanning payment platforms, cloud infrastructure providers, developer ecosystems, collaboration tools, and AI services. The report also identified 6.2 million credentials or authentication cookies tied to AI tools. The core problem for investigators: unlike human credentials, these NHIs often lack MFA enforcement, rotate infrequently, and operate with broad permissions. When exposed, they can provide attackers with persistent access to production systems, software supply chains, and cloud infrastructure.
The biggest forensic headache, though, is attribution. A shared service account credential always produces the same principal name in audit logs—regardless of which human, pipeline, or AI agent actually acted. As one vendor puts it: which agent dropped the table? Audit and forensics go blind the moment identity is shared. Even reconstructing a key’s origin is often impossible: there’s no way to know who has access to a key. Users may have downloaded it to their computer and shared it with others, which is something that you cannot track.
That said, modern cloud platforms do provide more granular trails for workload identity federation. In GCP, for instance, the resulting logs follow the same structure as other workload identity flows: the impersonated GCP Service Account appears in the principalEmail, while the original Kubernetes identity is captured in the serviceAccountDelegationInfo.principalSubject field, which includes the namespace and service account name, making it possible to determine exactly which KSA triggered the request. But these delegation chains are only useful if the relevant audit logs are enabled and centrally retained in the first place.
Practical Takeaways for IR Teams
For incident responders, the implication is clear: a playbook built only around human logins now covers just part of the attack surface. Making machine identities forensically traceable means moving decisively toward short-lived tokens instead of static keys, actively logging delegation chains and workload identity federation events, and building centralized, tamper-resistant audit log pipelines rather than relying on provider defaults. The UNC4899 case shows that the difference between catching an anomaly early and months of undetected compromise often comes down to exactly this groundwork.
← Back to overview