Cloud environments face risks not due to their speed, but because numerous unseen machine identities persist beyond effective control.
A recurring pattern in engineering projects involves a strong focus on deployment speed, commit velocity, and system uptime. However, a critical question often goes unaddressed: who truly manages the identities created during these processes?
This oversight is not intentional but systemic. The software delivery lifecycle is optimized for resource creation, yet lacks established practices for their removal. New services are celebrated upon launch, but their decommissioning often lacks a formal process.
This disparity has been observed over time. Systems are designed to scale rapidly, handling thousands of pods in seconds, while security governance models often remain reliant on manual approval processes. This creates a situation where advanced infrastructure is protected by outdated security measures.
Modern infrastructure has undergone fundamental changes, but identity governance practices have not kept pace. Efforts to audit and secure ephemeral workloads, which exist for mere milliseconds, often rely on methods designed for long-lived servers.
The Silent Explosion of Untracked Identities
Modern enterprise dashboards reveal a concerning metric: the sheer volume of entities behaving like employees, rather than just the number of human staff.
Each new human developer often leads to the unintentional creation of numerous machine identities. Service accounts, API keys, and workload tokens proliferate. Studies indicate that non-human identities now significantly outnumber human identities, often by a factor of 10 to 1 or more.
A typical microservice’s lifecycle, from development to production, can involve generating numerous distinct identities. These may include a GitHub token for the repository, a CI/CD service account for builds, a registry credential for container pushes, and various runtime roles for accessing databases, queues, and logging services.
The issue extends beyond sheer volume to invisibility. While human offboarding processes are standard, machine identities created by departing developers often remain active and unmonitored. These ‘zombie identities’ can retain administrative privileges long after their initial purpose is obsolete, frequently due to a reluctance to disable them.
The “Test Tenant” Trap
Many teams mistakenly believe that test environments are inconsequential, often stating, ‘It’s just dev; there’s no real customer data.’ This complacency is dangerous, as identity boundaries are seldom as distinct as perceived.
In practice, test environments frequently serve as initial targets for attackers, offering the path of least resistance. The Microsoft Midnight Blizzard attack exemplified this, where attackers exploited an unmonitored legacy test tenant instead of using a zero-day exploit.
Attackers compromised a non-human identity, using that access to infiltrate production corporate emails. Such identities are not benign remnants but potential backdoors. The risk stems from inter-environment connections; for instance, if a ‘test’ CI/CD runner can push to a ‘production’ container registry, or if passwords are reused, the ‘test’ designation provides a false sense of security.
Supply Chain Reliability as an Identity Challenge
The security of trusted tools is a critical concern. The Codecov incident, for example, highlighted a credential vulnerability rather than a code flaw, impacting confidence among engineering leaders.
Attackers in that incident extracted a credential during a Docker image creation process. They then used a static secret to hijack the Bash Uploader script, enabling them to modify it dynamically and transform a trusted development tool into a data exfiltration mechanism.
The current decade’s defining challenge involves the software supply chain, which relies on numerous API keys and secrets. Continued dependence on long-lived static credentials for pipeline integration creates inherent instability. Any static key within a repository, regardless of perceived privacy, represents a significant risk. A single accidental commit of a .env file or a compromised S3 bucket can expose critical access credentials.
The Acceleration of AI
While managing static bots presents significant challenges, the emergence of agentic AI introduces an even greater complexity.
There is a rapid deployment of AI agents capable of executing code, not just engaging in conversation. These autonomous workloads can access databases and initiate API calls, essentially functioning as highly privileged, machine-speed employees. Unlike deterministic automation scripts, AI agents are probabilistic, making decisions based on contextual information.
For example, an AI agent with broad permissions tasked with ‘optimizing cloud spend’ might inadvertently shut down a critical production database if it deems it ‘underutilized.’ Similarly, a prompt injection attack could coerce an AI agent into exfiltrating sensitive customer data.
Organizations that have not established robust identity governance for existing microservices are unprepared for autonomous AI. If an attacker compromises an AI agent, they gain its identity. Should that identity possess broad access due to simplified configuration, it effectively automates a data breach.
The Cultural Impact of Static Security Approaches
Beyond technical risks, the current approach to identity governance incurs a significant cultural cost. Slow, manual, and ticket-based governance processes can hinder engineering velocity.
Developers have been observed spending days awaiting ticket approval for basic access, such as read access to an S3 bucket. This friction often leads to Shadow IT, where developers, under pressure, circumvent official processes. They might share static keys via informal channels, hardcode credentials, or reuse high-privilege ‘admin’ keys for convenience, choosing the path of least resistance.
Ironically, stringent, gate-heavy control measures can result in reduced visibility and control. Modern identity governance should aim not to increase rejections, but to establish the secure path as the most efficient one.
Three Strategic Shifts for Improved Governance
Addressing these issues requires a framework that transitions from static reviews to continuous governance, as depicted in Figure 1. While no single solution exists, three engineering principles consistently mitigate risk without sacrificing velocity.
Figure 1: Governance must move from static reviews to a continuous lifecycle of issuance, verification and automated expiration.
1. Cryptographic Identity is Essential
Reliance on IP allowlists must cease. In dynamic container environments, network location is an inadequate indicator of trust.
The shift towards cryptographic identity is necessary. Every workload, regardless of its lifespan, should present a verifiable certificate. Frameworks such as SPIFFE enable the automatic issuance of short-lived identities to workloads. This approach fosters trust in the software itself, rather than its network connection. Known as ‘workload attestation,’ it verifies the binary executing a process before granting an identity document (SVID). A tampered binary would consequently receive no identity and no access.
2. Eliminate Static Credentials
Static keys represent technical debt, akin to ‘passwords on sticky notes’ in the cloud era.
The lifespan of credentials must be aggressively shortened. Human access should expire daily, while machine access should expire within minutes. A credential valid for only ten minutes significantly reduces its value to an attacker, fundamentally altering attack economics.
In practice, this involves adopting standards like OIDC Federation for CI/CD pipelines. Rather than storing a long-lived AWS secret in GitHub Actions, a build job can exchange a temporary token with AWS for short-lived access that expires upon build completion. This pattern, detailed by providers such as AWS and GitHub, completely addresses the ‘secret zero’ problem.
3. Automate Cleanup Processes
Manually reviewing tens of thousands of permissions is impractical and unsustainable.
The implementation of Cloud Infrastructure Entitlement Management (CIEM) is crucial for automating cleanup. Tools are needed to identify permissions actually utilized by a service account over a specified period, such as 90 days. If a permission, like writing to an S3 bucket, has not been used for three months, it should be automatically revoked. ‘Least Privilege’ should be viewed as an automated garbage collection process rather than merely a philosophy.
This automation is vital because human nature tends towards risk aversion. Engineers are understandably hesitant to cause an outage by deleting a key they believed was unused. Data-driven automation mitigates this fear, enabling confident privilege pruning.
Conclusion
Modern infrastructure is increasingly ephemeral, yet the prevailing mindset remains static.
Governing contemporary cloud environments with outdated tools is no longer viable. By embracing cryptographic identity and eradicating static secrets, systems can achieve both speed and security. The future of security involves creating safeguards that match the pace of development, rather than impeding it.
