Goodbye, Skeleton Keys: Why Machine Identity Broke IAM, and What SPIFFE Is Doing About It

Cloudflare published its own forensic timeline of the Salesloft Drift breach down to the minute, and it's worth sitting with the detail for a second. 

At 11:51 on August 9, 2025, an actor researchers track as GRUB1 tried to validate a stolen Cloudflare API token against the Salesforce API using TruffleHog's user-agent string — a tool built for finding leaked secrets, repurposed here to confirm one actually worked. That attempt failed. At 22:14, it didn't. 

GRUB1 walked into Cloudflare's Salesforce tenant using a credential that belonged to the Salesloft Drift integration, no exploit required, no privilege escalation needed — just a token that had been sitting there, valid, with no expiry pressure and no second factor to clear. 

Cloudflare wasn't an outlier. Google's Threat Intelligence Group eventually counted more than 700 organizations hit through that same OAuth token theft, including Google itself, Palo Alto Networks, and Proofpoint.

I keep coming back to that incident in conversations with platform teams, because it's the cleanest illustration I've seen of a problem that's now bigger than any single breach: we built identity and access management for humans, and then we quietly let it sprawl across a population of machines that outnumber humans by a ratio nobody fully agrees on, but everyone agrees is large. 

CyberArk's 2025 Identity Security Landscape study puts machine identities at more than 80 to 1 against human accounts in the average enterprise. Other measurements land lower or higher depending on methodology — the point isn't the exact multiple, it's that every credible number has been climbing for three straight years, and AI agents are the fastest-growing slice of it.

The Bottom Turtle

There's an old explanation of the universe — turtles all the way down — that the SPIFFE community borrowed for exactly this problem, sometimes literally titling their own documentation "Solving the Bottom Turtle." 

The question it's pointing at is uncomfortable: when service A needs to prove its identity to service B, what's the root of that trust? For most organizations through the 2010s, the honest answer was "a string." An API key baked into a config file. 

A service account password rotated, if you were disciplined, once a quarter. A shared secret copied from a wiki page that three former employees probably still remember. None of that was a deliberate architecture decision. It was what happened by default when nobody designed for machine-scale identity, because for most of computing history, nobody had to.

SPIFFE — the Secure Production Identity Framework for Everyone — came out of the people who hit that wall first, at the scale where it actually hurts: engineers from Google, Netflix, Pinterest, and Amazon, along with a startup called Scytale that's since been folded into Hewlett Packard Enterprise, pooling their separately built internal solutions into a shared open standard. 

SPIRE is the production-grade runtime that implements it, and both are now graduated projects under the Cloud Native Computing Foundation — the same governance tier Kubernetes itself holds. That's not a vanity badge. It signals that the CNCF's technical oversight committee considers the project's adoption and maturity broad enough to bet production infrastructure on, which is precisely what Uber, Block (formerly Square), Bloomberg, ByteDance, and the financial services firm Wise have done, each presenting their own deployment at SPIFFE community events over the past several years. 

Wise's case is the one I find most persuasive for regulated industries specifically: they adopted SPIRE to establish trust between systems operating across different regulatory jurisdictions, replacing shared secrets with something an auditor could actually verify cryptographically rather than take on faith.

What an SVID Actually Buys You

Strip away the acronyms, and the mechanism is fairly elegant. A SPIRE Agent runs on every node. When a workload starts up, the agent doesn't ask it to present a password — it interrogates the environment the workload is running in: which Kubernetes service account launched it, which container image hash it's running, which cloud instance metadata applies. 

That process is called attestation, and it's the part that matters most, because it ties identity to something an attacker can't simply copy out of a config file. If attestation succeeds, the agent requests a SPIFFE Verifiable Identity Document — an SVID — from the SPIRE Server: either an X.509 certificate for mutual TLS or a JWT for API-style calls, both scoped to a narrow lifetime, often measured in minutes rather than months.

That lifetime is the entire point. One practitioner walkthrough I'd recommend to any platform engineer puts the contrast plainly: steal a static API key and an attacker holds working access until someone notices and rotates it, a process that in real incident response routinely takes days. 

Steal an SVID, and the credential is already approaching its own expiration before anyone needs to act — the damage window is bounded by cryptographic TTL instead of by how fast your detection pipeline happens to be that week. Compare that against the Cloudflare timeline above, where the stolen token had no built-in clock running against the attacker at all.

Production deployments increasingly don't ask application code to deal with any of this directly. Service meshes absorb it at the infrastructure layer instead: Istio issues SPIFFE-compliant identities to every workload by default through its own internal certificate authority, and organizations that want centralized governance across mesh and non-mesh workloads alike can point Istio at an external SPIRE deployment instead, unifying the audit trail. 

Envoy proxies fetch SVIDs straight from a local SPIRE Agent through its Secret Discovery Service, which means mutual TLS between two services can be enforced with zero changes to either service's application code — the identity lives in the sidecar, not the business logic.

Where Cloud IAM Already Got This Half Right

None of this is unique to the open-source SPIFFE world, and it's worth being fair to the cloud providers here, because they solved an adjacent piece of the same problem years ago for one specific case: a workload calling its own cloud provider's APIs. 

AWS's IAM Roles for Service Accounts — IRSA — lets a pod running in EKS exchange a short-lived, Kubernetes-issued OIDC token for temporary AWS credentials, instead of mounting a static access key into the container image. 

Google Cloud's Workload Identity Federation and Azure's federated credentials do the structural equivalent for their own platforms. All three share the same underlying trick: trade a long-lived secret for a freshly minted, narrowly-scoped token, issued just-in-time, federated through an OIDC trust relationship rather than copy-pasted by a human.

The gap is what happens the moment a workload needs to talk to something that isn't its home cloud's API — another service on the same team's mesh, a partner's system in a different cloud, a vendor integration that predates anyone's identity strategy. AWS IAM has no opinion about a request arriving from GCP.

 That's the seam SPIFFE is built to close: a single SPIFFE ID and trust model that spans Kubernetes, VMs, multiple clouds, and on-prem hardware at once, with authorization policies written against that one identity rather than against whichever cloud-specific construct happens to apply this week. 

You can, and increasingly should, run both layers together — IRSA or Workload Identity Federation for the “talking to my own cloud” case, SPIFFE/SPIRE for everything else, federated through each cloud's OIDC provider so the two systems trust the same root rather than operating as separate, unrelated islands.

   Workload starts        |        v  SPIRE Agent  --attests workload-->  (checks: k8s service account,        |                              container image hash, node identity)        |  attestation OK        v  SPIRE Server  --issues-->  SVID (X.509 cert or JWT, TTL: minutes)        |        +----> mTLS to peer workload (via Envoy/Istio sidecar, SPIFFE ID in cert SAN)        |        +----> OIDC Federation --> Cloud IAM (AWS STS / GCP WIF) --> short-lived cloud creds        |        +----> SVID expires automatically; re-attestation required for renewal

The Part Agentic AI Just Made Worse

Everything above was already a hard problem before AI agents entered the picture, and the agents have not been gentle with it. 

Gartner flagged non-human identity management as a top 2025 strategic trend specifically because of agentic AI's growth curve, and OWASP responded with a dedicated Non-Human Identity Top 10 the same year — an acknowledgment that neither traditional application security tooling nor human-centric IAM processes were built with credentials that never sleep, never log in interactively, and frequently outlive the project that created them. 

The npm worm campaigns that tore through the back half of 2025 made the failure mode concrete rather than theoretical: forensic write-ups of the Shai-Hulud malware describe it actively harvesting environment variables and any cloud credentials exposed through instance metadata services on infected build runners — precisely the long-lived, broad-scope keys that IRSA and Workload Identity Federation exist to eliminate, sitting unprotected because someone, somewhere, found it easier to bake in a static key than to wire up federation.

And then there's the harder case, the one that should concern anyone running agentic systems in production: Anthropic's account of the GTG-1002 espionage campaign in late 2025 described a threat actor manipulating an AI coding agent into autonomously executing the bulk of an intrusion across roughly thirty targets. 

An agent acting with that kind of autonomy needs some identity to operate under. If that identity is a copied human credential or a static service account with standing privilege — the skeleton-key pattern this whole piece has been arguing against — then a manipulated agent inherits every door that credential opens, instantly, at whatever speed the agent can issue requests. 

If instead it's a narrowly attested, short-lived SVID scoped to exactly the tools that the agent's task requires, the same manipulation still happens, but the blast radius it can reach is bounded by design rather than by luck.

Where This Actually Goes in Practice

Nobody serious is suggesting a rip-and-replace migration, and the practitioners who've done this well consistently describe a phased rollout instead: stand up SPIRE on Kubernetes first, prove mTLS between two or three high-value internal services, then move to eliminating the cloud credential files with the broadest blast radius — typically the workloads touching object storage or managed databases — before tackling legacy VMs and anything that predates the cluster entirely. 

None of it requires abandoning Vault, AWS Secrets Manager, or whatever secrets store already exists; SPIFFE is narrower than that, it specifically removes the class of secret used purely to prove "I am workload X," and leaves genuine application secrets — database passwords for systems that haven't adopted modern identity, third-party API keys — to whatever vault you're already running, just with a shrinking footprint over time.

The IETF formalized a working group for Workload Identity in Multi-System Environments in 2024, which tells you where the standards body sees this heading: not as a niche Kubernetes pattern, but as infrastructure plumbing on the same tier as TLS itself. 

My honest read, watching this mature over the past two years: a decade from now, handing a workload a static, long-lived credential is going to look the way handing an employee a permanent admin password without MFA looks today — technically functional, and a decision nobody will be able to defend after the fact.