Platform Engineering’s Next Challenge: Managing Millions of Machine Identities 

Every pipeline your platform triggers creates something that has to prove who it is. A pod comes up and needs a token. A GitHub Actions runner spins up and needs to reach an S3 bucket. A CI job needs to talk to Terraform Cloud. An AI agent needs to call three internal APIs on your behalf, unsupervised, at two in the morning. None of these are people. All of them need an identity, and somebody — usually your platform team, whether they signed up for it or not — has to issue it, scope it, rotate it, and eventually kill it. 

For the last five years, platform engineering has organized itself around a fairly clean story: Golden paths, self-service portals, internal developer platforms (IDPs), reduced cognitive load for application teams. That story is still true. It’s just no longer the whole story. The number of non-human identities in a typical enterprise now dwarfs the human headcount by an order of magnitude most engineering leaders haven’t internalized yet, and the systems platform teams built to make developers faster are, unintentionally, the systems now spinning up the majority of that growth. 

This isn’t a security team’s problem that platform engineering happens to be adjacent to. It’s a platform design problem that security teams are currently absorbing the consequences of. 

The Number That Should Stop You 

<cite index=”5-1″>Organizations now manage an average of 109 machine identities for every human identity, according to Palo Alto Networks’ 2026 Identity Security Landscape report</cite>. That ratio was 82:1 in the same survey the year prior — a jump that tracks almost exactly with the mainstreaming of Kubernetes-native CI/CD, service mesh adoption, and, increasingly, AI agents that spin up their own sub-processes. <cite index=”5-1″>The same report projects machine identity volume will grow 77% over the next twelve months, against 56% growth in human identities — and AI agents specifically are expected to grow 85%</cite>. Other independent research puts the ratio lower — Security Boulevard’s July 2026 analysis cites a 45:1 non-human-to-human ratio from a separate dataset — but even the conservative estimate is a multiple most identity programs weren’t architected for. <cite index=”7-1″>A separate set of 2025 studies tracked roughly 44% year-on-year growth in non-human identities, with machine-to-human ratios climbing from around 80:1 toward 144:1 in some environments.</cite> The exact multiplier depends on who’s counting and what they’re counting, but every methodology points the same direction, and it’s not slowing down. 

The market is pricing this in. <cite index=”2-1″>The global machine identity security market was valued at roughly $9.85 billion in 2025 and is projected to reach $26.97 billion by 2035</cite>, a compound annual growth rate north of 10%. That’s not hype-cycle money. That’s enterprise budget owners deciding, quietly and in large numbers, that this line item isn’t optional anymore. 

Platform Engineering Didn’t Ask for This — It Built it Anyway 

Walk through the evolution and it’s obvious in hindsight. Traditional infrastructure teams gave way to DevOps, which gave way to platform engineering, which gave way to IDPs — Backstage catalogs, Crossplane compositions, golden-path templates that let a developer go from git init to a running service in an afternoon. Every one of those advances was, correctly, framed as a productivity win. 

What nobody put on the roadmap was that every one of those advances is also an identity-issuance event. A golden path that spins up a new microservice also spins up a Kubernetes service account, a cloud IAM role, possibly a database credential, and a CI/CD pipeline identity to deploy it — usually with defaults nobody revisited after the template was written. Platform teams became, without much deliberation, the largest issuers of machine identity in the organization. They just didn’t think of themselves that way, because the mental model was “we ship infrastructure,” not “we mint trust.” 

That gap between what platform teams think they own and what they actually control is where most of the current mess comes from. 

What’s Actually Multiplying 

It helps to be concrete about what counts as a machine identity in a modern stack, because the category is wider than most inventories capture: Kubernetes pods and service accounts, containers, cloud IAM roles, SPIFFE/SPIRE-issued workload identities, TLS certificates, GitHub Actions and GitLab CI runners, Terraform and Pulumi execution identities, ArgoCD and Flux reconciliation credentials, Jenkins agents, serverless function roles, service mesh sidecars, database connection credentials, message queue clients, IoT device certificates — and now, AI agents and the MCP (Model Context Protocol) servers they talk to. 

Each of those categories was manageable in isolation five years ago. What changed is ephemerality and scale acting together. Autoscaling means identities are created and destroyed by the thousands per day, not provisioned once by a human who remembers doing it. Multi-cloud and hybrid environments mean the same workload might authenticate three different ways depending on where it happens to be running that hour. And now agentic AI adds a genuinely new wrinkle: identities that don’t just authenticate once and sit still, but that reason, chain tool calls, delegate to sub-agents, and act across trust boundaries without a human confirming each step. 

<cite index=”30-1″>Unlike a static service account or API key, an agentic identity is dynamic, ephemeral, and autonomous — it reasons, delegates, and acts across domains and trust zones, which is exactly why legacy non-human-identity models don’t map cleanly onto it.</cite> That’s not a minor taxonomy note. It means the identity tooling built for “this service always calls that service” doesn’t hold up when the caller’s behavior is generated at runtime by a model. 

Why the Old Playbook Breaks 

Traditional IAM was built for a world with a directory, a login form, and a human on the other end who could be asked to re-authenticate. Machine identity breaks nearly every assumption in that model: 

Credentials outlive their usefulness. Long-lived API keys and static secrets get embedded in config files, CI variables, and container images, and then nobody remembers to rotate them because nothing forces the issue. <cite index=”4-1″>GitGuardian’s telemetry shows leaked secrets have grown 152% since 2021, while GitHub’s public developer base grew only 98% over the same period — secrets sprawl is outpacing the population of developers creating them</cite>, and <cite index=”4-1″>AI-assisted commits are now leaking secrets at roughly twice the baseline rate across public GitHub</cite>. This isn’t a hypothetical trend line. It’s happening inside the exact tooling platform teams rolled out to make developers faster. 

Remediation is slow relative to the threat. <cite index=”29-1″>When AWS credentials are exposed publicly, attackers typically attempt to use them within about 17 minutes — while nearly a quarter of organizations take more than 24 hours to rotate the exposed credential</cite>. <cite index=”29-1″>GitGuardian’s retesting of secrets confirmed valid in 2022 found that 64% still hadn’t been revoked as of January 2026</cite> — four years of open exposure for a credential that should have died in an afternoon. 

MCP has opened a fresh, largely unguarded door. <cite index=”29-1″>In a study of nearly 8,000 live MCP servers, 40% had no authentication configured at all, and every OAuth-enabled server tested carried at least one flaw</cite>. And it’s not just runtime auth — <cite index=”29-1″>24,008 unique secrets were found hardcoded into MCP configuration files on public GitHub within the protocol’s first year</cite>, partly because early quickstart documentation normalized pasting API keys directly into config. 

Tooling adoption is badly outrunning governance. <cite index=”29-1″>Agent framework packages — LangChain, LangGraph, CrewAI, the OpenAI Agents SDK, LlamaIndex, and similar — pulled 483 million downloads in May 2026 alone, against 5.8 million downloads for agent security and guardrail packages in the same month: an 83-to-1 gap that had been 59-to-1 just four months earlier</cite>. That ratio isn’t stabilizing. It’s widening by the month, which tells you where the industry’s attention currently is and isn’t. 

Visibility is close to nonexistent. <cite index=”33-1″>A Cloud Security Alliance survey found 68% of organizations cannot reliably distinguish AI agent activity from human activity in their own environments</cite>, and <cite index=”33-1″>only 5.7% of organizations report full visibility into their service accounts</cite>. Separately, <cite index=”36-1″>Veza’s 2026 State of Identity and Access report found that a mere 0.01% of non-human identities control 80% of cloud resources</cite> — a concentration of blast radius most security teams don’t have on a dashboard anywhere. 

The business impact of all this isn’t abstract. <cite index=”10-1″>CyberArk surveyed more than 1,200 security leaders for its 2025 State of Machine Identity Security Report and found that 67% of UK respondents had suffered at least one certificate-related outage in the past year, with 52% experiencing outages monthly and 31% weekly</cite>. <cite index=”10-1″>Nearly half — 43% — of UK security leaders reported a security incident or breach tied to a compromised machine identity in the last year, which in turn caused delayed application launches, customer-facing outages, and unauthorized access to sensitive data</cite>. And this isn’t just a security-team headache: <cite index=”20-1″>Keyfactor’s 2024 PKI and Digital Trust Report found respondents experienced an average of three outages caused by expired certificates over 24 months, taking roughly 2.6 hours to identify the root cause and another 2.7 hours to remediate</cite> — hours that translate directly into lost revenue on any customer-facing system. 

Google’s own Bazel team learned this the hard way over the 2025 winter holidays, when <cite index=”25-1″>an SSL certificate for two Bazel build-infrastructure domains expired on Boxing Day, quietly breaking builds until someone noticed</cite>. On the more dramatic end, <cite index=”24-1″>an expired Ericsson certificate once knocked O2’s UK network offline for nearly a full day, and Ericsson ultimately paid roughly $132.8 million in compensation</cite>. These aren’t obscure edge cases. They’re the predictable output of treating certificate and credential lifecycle as an operational afterthought rather than a platform-owned capability. 

And the ground is about to shift further under everyone’s feet. <cite index=”4-1″>In April 2025 the CA/Browser Forum unanimously approved Ballot SC-081v3, cutting the maximum public TLS certificate lifetime from 398 days to 200 days starting March 2026, then to 100 days in March 2027, and to 47 days by March 2029</cite> — an eightfold increase in annual renewal frequency from today’s baseline. Manual certificate management, which was already failing at 398-day intervals, is not going to survive 47-day ones. Full stop. 

The Reframe: Identity is a Platform Capability, not a Security Bolt-On 

Here’s the turning point that most organizations are still missing. The instinct is to ask “how do we secure these identities better?” and hand the question to the security team. The better question — the one platform engineering is actually positioned to answer — is “how should the platform be issuing identities in the first place?” 

Platform teams already own provisioning templates, CI/CD pipelines, cluster policies, and the golden paths developers walk through to ship anything. That means they already, functionally, control identity creation — they just haven’t been designing for it deliberately. Treating identity as a first-class platform capability, engineered with the same rigor as compute provisioning or observability, is the actual shift happening at the leading edge of the discipline right now. Not “add a secrets scanner.” Redesign the golden path so that no workload is ever handed a long-lived static credential in the first place. 

What Identity-Aware Platforms Actually Look Like 

This is where the work gets concrete, and where the industry has, genuinely, converged on a reasonably coherent set of patterns. 

Issuance. The baseline shift is from long-lived, manually rotated credentials to short-lived, automatically issued ones. SPIFFE (Secure Production Identity Framework for Everyone) and its implementation, SPIRE, have become the closest thing to a standard here. <cite index=”17-1″>SPIFFE entered CNCF in March 2018 and reached Graduated maturity — the foundation’s highest bar — in August 2022</cite>, and adoption at genuine scale is well documented. <cite index=”12-1″>ByteDance built a zero-trust infrastructure on SPIFFE/SPIRE to secure hundreds of thousands of workloads</cite>, and Uber’s platform authentication team has described it as the north-star foundation for securing production interactions across the company. The core primitive is the SVID (SPIFFE Verifiable Identity Document) — <cite index=”13-1″>a short-lived credential, typically an X.509 certificate or JWT, that a workload presents to prove its identity without relying on a shared secret</cite>. It’s worth being honest about the gaps too: <cite index=”16-1″>the SPIFFE project has known about a JWT-SVID replay vulnerability since at least 2023, and is now converging on the IETF’s separately-developed Workload Identity Token standard rather than the fix it originally proposed</cite>. Maturity doesn’t mean the problem is solved. It means the community is honest enough to say what isn’t. 

Authentication. Mutual TLS between workloads, OIDC federation for CI/CD systems reaching cloud providers, and — new as of this year — OAuth 2.1 for AI agents authenticating to MCP servers. <cite index=”36-1″>Auth0’s “Auth for MCP” went generally available on May 6, 2026, and Okta released its own MCP server enabling agents to reach Okta’s management APIs under least-privilege, scoped access enforced at each individual tool call</cite> — a signal that the major identity vendors have stopped treating agent authentication as a future problem. 

Authorization. Least privilege enforced by policy engines rather than static role assignments, ideally attribute- and context-aware rather than a flat permission list assigned once at creation and never revisited. For agentic workloads specifically, the emerging pattern is delegation rather than impersonation — <cite index=”28-1″>issuing the agent its own uniquely scoped identity rather than letting it silently act under a human’s or service’s broader credentials</cite>, with access decisions made continuously rather than once at login. As Ping Identity CEO Andre Durand put it at Identiverse 2026, the industry is moving toward governing <cite index=”28-1″>”actions, not access”</cite> — continuous, real-time decisions about what an entity is doing, not a one-time gate at the door. 

Secrets management. Dynamic, short-lived secrets issued on demand rather than static values sitting in a vault indefinitely, with automatic rotation as the default rather than a manual quarterly task somebody eventually stops doing. 

Lifecycle. Creation, rotation, expiration, and revocation need to be automated end-to-end, because — as the 47-day certificate future makes brutally clear — manual rotation cadences are about to become mathematically impossible to sustain at any real scale. 

Observability. An actual, current inventory of every machine identity, its owner, its scope, and its last-used timestamp. This sounds basic. <cite index=”33-1″>Only 5.7% of organizations currently have it</cite>, which tells you it isn’t. 

A Reference Flow, in Plain Terms 

Strip the marketing diagrams away and the trust flow through a well-built identity-aware IDP looks roughly like this: a developer merges code through a golden path; the CI/CD system authenticates to the cloud provider via short-lived OIDC federation rather than a stored secret; the deployed workload gets attested and issued a SPIFFE identity by the platform’s identity service at runtime, not baked into an image at build time; the service mesh enforces mutual TLS between workloads using those identities; cloud IAM roles are assumed just-in-time rather than held statically; and every step of that chain — issuance, use, rotation, revocation — feeds into a central identity inventory that security and platform teams both actually look at. <cite index=”14-1″>Attestation in this model isn’t a static assignment — it’s a verification process where the SPIRE agent checks environmental attributes like the Kubernetes service account, container image hash, or filesystem path before it issues an identity, tying that identity to a real, verifiable runtime condition rather than a label someone typed in once</cite>. 

What to Actually Measure 

DORA metrics tell you how fast and reliably you ship. They tell you nothing about whether what you shipped is trustworthy. A platform maturing around identity should be tracking, at minimum: the percentage of workload credentials that are short-lived versus static; average credential lifetime across the fleet; how often certificates and secrets actually rotate versus how often the policy says they should; the rate of certificate-expiration incidents; adoption of workload identity (SPIFFE/SPIRE or equivalent) as a percentage of total workloads; time from request to identity provisioning; and — increasingly critical — the percentage of AI agents with a defined owner, a documented purpose, and a bounded access scope, since <cite index=”5-1″>most organizations today can explain what their AI agents are for, but far fewer can say what those agents can actually access, how that access is limited, or when it gets revoked</cite>. 

The AI-Native Platform is Already Here, not Coming 

It’s tempting to file “AI agent identity” under future-proofing. It isn’t. <cite index=”31-1″>Enterprises across finance, healthcare, and IT already run autonomous agents that chain multi-step API calls through protocols like MCP and A2A, spawn their own sub-agents, and act across organizational boundaries without continuous human supervision</cite> — and the failure modes are already cataloged, not theoretical. <cite index=”31-1″>Once an agent authenticates to an MCP server, it typically gains implicit access to every tool that server exposes, with no per-tool credential check</cite>, and because tools often share a server’s execution context, <cite index=”31-1″>a tool invoked with low-sensitivity input can be manipulated into performing a high-sensitivity action using the server’s ambient privileges</cite> — a confused-deputy problem platform teams have mostly not had to reason about before. 

The standards response is moving fast enough to track in real time: <cite index=”36-1″>MCP OAuth 2.1 is now under Linux Foundation governance, Microsoft’s Entra Agent ID has reached general availability, and the Cloud Security Alliance has published an Agentic Trust Framework to give the industry shared vocabulary for this</cite> — but as one recent analysis put it bluntly, <cite index=”36-1″>standards are not implementations</cite>, and most organizations are still running disconnected authentication for their agent infrastructure rather than routing it through their existing identity provider. 

What to Actually Do About It 

None of this requires a rip-and-replace. It requires platform teams to stop treating identity as something that happens to their golden paths and start treating it as something their golden paths deliberately produce. 

• Inventory before you architect. You cannot secure what you can’t see, and most organizations currently can’t see most of it. 

• Default every new golden path to short-lived, workload-scoped credentials — no static secrets in a new service template, full stop. 

• Route AI agents through the same identity plane as your human and service identities, not a bolt-on side system nobody else looks at. 

• Automate certificate rotation now, ahead of the 200-day mandate in March 2026, not after it forces the issue. 

• Assign an explicit owner and access scope to every AI agent before it goes into production, not after an incident makes you go find one. 

• Put machine identity metrics on the same dashboard as your reliability metrics, reviewed with the same seriousness. 

Where This is Heading 

Platform engineering’s first decade was about making infrastructure disappear behind a good developer experience. Its next chapter is going to be about making trust automatic instead of assumed. The organizations that get ahead of this won’t be the ones with the flashiest developer portal — they’ll be the ones whose every workload, service, and autonomous agent can prove, cryptographically and continuously, who it is and what it’s allowed to do. Given that machine identities are already outnumbering human ones by more than a hundred to one and growing faster every quarter, that capability isn’t a nice-to-have on the platform roadmap. It’s about to be the roadmap.