{"id":15787,"date":"2026-02-12T10:06:31","date_gmt":"2026-02-12T10:06:31","guid":{"rendered":"https:\/\/newestek.com\/?p=15787"},"modified":"2026-02-12T10:06:31","modified_gmt":"2026-02-12T10:06:31","slug":"the-ephemeral-infrastructure-paradox-why-short-lived-systems-need-stronger-identity-governance","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=15787","title":{"rendered":"The ephemeral infrastructure paradox: Why short-lived systems need stronger identity governance"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

In my experience leading engineering projects, I have encountered the same pattern repeatedly. We obsess over deployment speed. We measure success in commit velocity and uptime. But we rarely pause to ask the most uncomfortable question in the room: Who actually owns the identities we just spun up?<\/p>\n

This silence isn\u2019t malicious; it\u2019s structural. We have optimized our entire software delivery lifecycle for the creation of resources, but we have almost no muscle memory for their destruction. We celebrate the \u201cHello World\u201d of a new service, but we have no ceremony for its decommissioning.<\/p>\n

For years, I watched this disconnect play out. I would sit in planning meetings where we architected systems to scale to thousands of pods in seconds. Yet, our security governance model was still stuck in the era of manual ticket approvals. We were building Ferraris and trying to secure them with bicycle locks.<\/p>\n

The reality today is that our infrastructure has fundamentally changed, but our identity governance has not. We are still trying to audit ghosts. We attempt to secure ephemeral workloads that live for milliseconds using spreadsheets designed for servers that last for years.<\/p>\n

<\/a>The silent explosion we\u2019re not tracking<\/h2>\n

If you look at the dashboards of any modern enterprise today, you will see a metric that should keep you up at night. It is not the number of employees you have. It is the number of things acting like employees<\/em>.<\/p>\n

For every human developer onboarded, we inadvertently create a massive number of machine identities. Service accounts, API keys and workload tokens accumulate like digital dust. Research suggests that non-human identities now outnumber humans<\/a> by a factor of 10 to 1 or more.<\/p>\n

Consider the lifecycle of a typical microservice. In its journey from a developer\u2019s laptop to production, it might generate a dozen distinct identities: a GitHub token for the repository, a CI\/CD service account for the build, a registry credential to push the container, and multiple runtime roles to access databases, queues and logging services.<\/p>\n

The problem is not just volume; it is invisibility. When a developer leaves, HR triggers an offboarding process. Their email is cut, their badge stops working. But what about the five service accounts they hardcoded into a deployment script three years ago? Those usually stay active, unmonitored, waiting for someone to find them. Often, these \u201czombie identities\u201d retain administrative privileges long after their original purpose has vanished, simply because no one is brave enough to turn them off.<\/p>\n

<\/a>The \u201ctest tenant\u201d trap<\/h2>\n

I have seen too many teams fall into the trap of thinking a test environment does not matter. \u201cIt\u2019s just dev,\u201d they say. \u201cThere\u2019s no real customer data there.\u201d This complacency is fatal because identity boundaries are rarely as clean as we think they are.<\/p>\n

In reality, test environments are often where attackers go first. It is the path of least resistance. We saw this play out in the Microsoft Midnight Blizzard attack<\/a>. The attackers did not burn a zero-day exploit to break down the front door; they found a legacy test tenant that nobody was watching closely.<\/p>\n

They compromised a non-human identity and used that access to pivot straight into production corporate emails. These are not harmless leftovers. They are open backdoors. The danger lies in the relationships between environments. If a \u201ctest\u201d CI\/CD runner has permission to push to a \u201cproduction\u201d container registry, or if a developer reuses a password across both environments, the \u201ctest\u201d label is nothing more than a false sense of security.<\/p>\n

<\/a>Supply chain reliability is an identity problem<\/h2>\n

We also need to talk about the tools we trust. The Codecov incident<\/a> shook the confidence of every engineering lead I know because it wasn\u2019t a code vulnerability\u2014it was a credential vulnerability.<\/p>\n

Attackers extracted a credential from a Docker image creation process. They used a static secret to hijack the Bash Uploader script. This allowed them to modify the script on the fly, effectively turning a trusted development tool into a data exfiltration engine.<\/p>\n

This is the defining challenge of our decade. Our software supply chain is held together by thousands of API keys and secrets. If we continue to rely on long-lived static credentials to glue our pipelines together, we are building on sand. Every static key sitting in a repo\u2014no matter how private you think it is\u2014is a ticking time bomb. It only takes one developer to accidentally commit a .env file or one compromised S3 bucket to expose the keys to the kingdom.<\/p>\n

<\/a>The AI acceleration<\/h2>\n

If managing static bots feels like drowning, the rise of agentic AI is about to hand us a firehose.<\/p>\n

We are rushing to deploy AI agents that do not just chat\u2014they execute code. These are autonomous workloads that can read databases and trigger API calls. An AI agent is effectively a highly privileged employee that works at machine speed. Unlike traditional automation scripts, which are deterministic and follow a strict set of instructions, AI agents are probabilistic. They make decisions based on context.<\/p>\n

If an AI agent is tasked with \u201coptimizing cloud spend,\u201d and it has broad permissions, it might decide to shut down a critical production database because it deemed it \u201cunderutilized.\u201d Or, if it is tricked by a prompt injection attack, it could be coerced into exfiltrating sensitive customer data.<\/p>\n

If you have not solved identity governance for your existing microservices, you are not ready for autonomous AI. If an attacker compromises an AI agent, they inherit its identity. If that identity has broad access because \u201cit was easier to configure that way,\u201d you have automated your own data breach.<\/p>\n

<\/a>The cultural cost of static security<\/h2>\n

Beyond the technical risks, there is a profound cultural cost to our current approach. When identity governance is slow, manual and ticket-based, it becomes an adversary to engineering velocity.<\/p>\n

I have seen developers spend days waiting for a ticket to be approved just to get read access to an S3 bucket. This friction breeds Shadow IT<\/a>. Developers, under pressure to ship, will bypass the official process. They will share static keys over Slack, hardcode credentials into their apps or reuse a high-privilege \u201cadmin\u201d key for everything because it\u2019s the path of least resistance.<\/p>\n

Paradoxically, by trying to control everything with heavy-handed gates, we end up with less visibility and less control. The goal of modern identity governance shouldn\u2019t be to say \u201cno\u201d more often; it should be to make the secure path the fastest path.<\/p>\n

<\/a>3 strategic shifts<\/h2>\n

How do we fix this? As illustrated in Figure 1, we need a framework that shifts from static reviews to continuous governance. There are no silver bullets, but three engineering principles consistently reduce risk without killing velocity.<\/p>\n

\n
srcset=”https:\/\/b2b-contenthub.com\/wp-content\/uploads\/2026\/02\/workload-identity-architecture.png?quality=50&strip=all 672w, https:\/\/b2b-contenthub.com\/wp-content\/uploads\/2026\/02\/workload-identity-architecture.png?resize=300%2C166&quality=50&strip=all 300w, https:\/\/b2b-contenthub.com\/wp-content\/uploads\/2026\/02\/workload-identity-architecture.png?resize=150%2C84&quality=50&strip=all 150w, https:\/\/b2b-contenthub.com\/wp-content\/uploads\/2026\/02\/workload-identity-architecture.png?resize=640%2C354&quality=50&strip=all 640w, https:\/\/b2b-contenthub.com\/wp-content\/uploads\/2026\/02\/workload-identity-architecture.png?resize=444%2C246&quality=50&strip=all 444w” width=”672″ height=”372″ sizes=”auto, (max-width: 672px) 100vw, 672px”>
Figure 1: Governance must move from static reviews to a continuous lifecycle of issuance, verification and automated expiration.<\/em><\/figcaption><\/figure>\n

Niranjan Kumar Sharma<\/p>\n<\/div>\n

<\/a>1. Identity must be cryptographic<\/h3>\n

We must stop relying on IP allowlists. In a world of dynamic containers, network location is a poor proxy for trust.<\/p>\n

We need to move toward cryptographic identity. Every workload must present a verifiable certificate, whether it lives for five years or five milliseconds. Frameworks like SPIFFE<\/a> allow us to issue short-lived identities to workloads automatically. This means we trust the software, not the network cable it is plugged into. This approach, often called \u201cworkload attestation,\u201d verifies the binary running the process before issuing it an identity document (SVID). If the binary has been tampered with, it gets no identity and therefore, no access.<\/p>\n

<\/a>2. Kill the static credential<\/h3>\n

Static keys are technical debt. They are the \u201cpassword on a sticky note\u201d of the cloud era.<\/p>\n

We need to aggressively shorten the lifespan of credentials. If a human needs access, it should expire at the end of the day. If a machine needs access, it should expire in minutes. When a credential works for only ten minutes, its value to an attacker drops to near zero. You fundamentally change the economics of the attack.<\/p>\n

Practically, this means adopting standards like OIDC Federation for your CI\/CD pipelines. Instead of storing a long-lived AWS secret in your GitHub Actions settings, your build job should exchange a temporary token with AWS to get short-lived access that expires the moment the build finishes. This pattern, documented extensively by providers like AWS<\/a> and GitHub<\/a>, eliminates the \u201csecret zero\u201d problem entirely.<\/p>\n

<\/a>3. Automate the cleanup<\/h3>\n

We cannot manually review 50,000 permissions. The math does not work.<\/p>\n

We must use Cloud Infrastructure Entitlement Management (CIEM)<\/a> to automate the cleanup. We need tools that look at what permissions a service account actually used<\/em> in the last 90 days. If it hasn\u2019t written to that S3 bucket in three months, revoke the permission automatically. Treat \u201cLeast Privilege\u201d not as a philosophy, but as an automated garbage collection process.<\/p>\n

This automation is critical because humans are naturally risk-averse. No engineer wants to be the one who caused an outage by deleting a key they thought<\/em> was unused. Data-driven automation removes that fear, allowing us to prune privileges with confidence.<\/p>\n

<\/a>Final thoughts<\/h2>\n

The infrastructure we build has become ephemeral. Yet our mindset is still static.<\/p>\n

We cannot continue to govern modern cloud environments with the tools of the past decade. By adopting cryptographic identity and eliminating static secrets, we can build systems that are fast and<\/em> secure. The future of security is not about slowing down; it is about building guardrails that move as fast as we do.<\/p>\n

This article is published as part of the Foundry Expert Contributor Network.
Want to join?<\/a><\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

In my experience leading engineering projects, I have encountered the same pattern repeatedly. We obsess over deployment speed. We measure success in commit velocity and uptime. But we rarely pause to ask the most uncomfortable question in the room: Who actually owns the identities we just spun up? This silence isn\u2019t malicious; it\u2019s structural. We have optimized our entire software delivery lifecycle for the creation… <\/p>\n

Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-15787","post","type-post","status-publish","format-standard","hentry","category-uncategorized","is-cat-link-borders-light is-cat-link-rounded"],"_links":{"self":[{"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/posts\/15787","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=15787"}],"version-history":[{"count":0,"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/posts\/15787\/revisions"}],"wp:attachment":[{"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=15787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}