On 5 September 2025, researchers at GitGuardian published findings they called the GhostAction campaign: 327 GitHub accounts compromised, malicious workflows injected across 817 repositories, 3,325 secrets extracted from CI/CD environments before detection. The secrets were not passwords. Passwords, by 2025, had been subjected to decades of engineering attention: hashed, salted, rate-limited, replaced in many contexts by hardware-backed passkeys or FIDO2 authenticators that cannot be phished. The secrets stolen in the GhostAction campaign were API keys, access tokens, and service credentials. The kind of static string an automated system presents to identify itself, committed by accident into a repository, rotated manually when someone remembers, never expiring otherwise.
GitGuardian's 2026 State of Secrets Sprawl report recorded 28.65 million new hardcoded secrets added to public GitHub repositories in 2025 alone: a thirty-four per cent increase over the preceding year. The individual engineers responsible are doing something careless. The industry that has provided no better default for machine authentication is doing something structural.
#02The decade of human authentication
The contrast between how human authentication and machine authentication progressed over the past decade is sharp enough that stating it plainly feels like overstatement. It is not.
From 2013 to 2023, human authentication received sustained, serious engineering attention across the industry. The FIDO Alliance published the U2F specification in 2013 and the FIDO2 specification in 2018. WebAuthn became a W3C Recommendation in that same year. Apple introduced passkey support in iOS 16 in 2022; Google began rolling out passkeys as the default sign-in mechanism in late 2023. The protocol progression moved from time-based one-time passwords, which remain guessable if intercepted and require the user to carry a secret seed, to hardware security keys, which bind authentication to possession of a specific device, to passkeys: cryptographic credentials generated on-device, tied to a platform authenticator, non-exportable, immune to phishing by construction.
Each step in this sequence addressed a specific weakness in the previous approach. Each step required coordination across browser vendors, platform vendors, standards bodies, and relying parties. The investment was visible, the progress was documented, and the security improvement was real. By 2025, a person authenticating to a well-run consumer or enterprise service could do so with a credential that lived in hardware, that had never been transmitted across a network, and that could not be obtained by an attacker who obtained the server's credential store. Meanwhile, a service calling another service typically presented a string of characters in an HTTP header.
#03The gap that persisted
The machine authentication problem is structurally different from the human authentication problem, and this difference has sometimes been offered as an explanation for why it received less attention. Machines cannot tap a hardware token. The interaction model that works for a person signing in to a web application does not translate to a container calling an API at startup. That structural difference is real. It has also been used, consciously and otherwise, to defer the question of machine authentication rather than to route it toward appropriate solutions.
The solution that persisted in the interim was the shared secret: an API key, a service account password, a connection string, a static OAuth client secret. Credentials that exist outside the entity holding them, that can be copied without detection, that do not expire automatically, and that must be rotated manually. The operational burden of rotating shared secrets at scale is familiar to anyone who has managed a service estate of more than a few dozen components. A credential placed in a configuration file was manually placed there and will be manually updated until it leaks or until the service is decommissioned, whichever comes first.
#04The infrastructure that was already there
On 20 September 2022, the Cloud Native Computing Foundation announced that SPIFFE and SPIRE had graduated to CNCF graduated status: the same tier as Kubernetes, Prometheus, and Envoy. The announcement did not receive front-page attention. The AI wave had already arrived; the focus of the industry was elsewhere.
SPIFFE, the Secure Production Identity Framework For Everyone, is a specification for workload identity. Its core artefact is the SVID, the SPIFFE Verifiable Identity Document: an X.509 certificate with a URI subject alternative name of the form spiffe://trust-domain/path. The certificate is short-lived by specification, valid for one hour or less in SPIRE's reference implementation, automatically rotated before expiry, and bound to the specific workload that received it through an attestation process that verifies the requesting process is what it claims to be before issuing anything. An attacker who obtains an SVID has a credential that has already expired. An attacker who obtains an API key has a credential that is valid until someone notices and rotates it.
Istio and Linkerd, the two most widely deployed service mesh implementations, use SPIFFE SVIDs for workload identity and issue them through SPIRE or compatible implementations. Organisations running Kubernetes at scale had been operating this infrastructure for several years before the AI agent conversation began, without calling it a revolution, because revolutions are not what happens when plumbing works correctly.
The IETF OAuth working group published the first draft of draft-ietf-oauth-spiffe-client-auth in June 2026: a specification for using SPIFFE SVIDs as the client authentication method in OAuth 2.0 token requests. When it reaches RFC status, a workload will be able to authenticate to an OAuth authorisation server using its short-lived cryptographic identity rather than a pre-shared client secret. The draft is evidence that the ecosystem is moving toward closing the gap between SPIFFE-issued identity and the OAuth-based authorisation flows that the rest of the application layer uses. It is also evidence that the gap has not yet fully closed.
“An attacker who obtains an SVID has a credential that has already expired. An attacker who obtains an API key has a credential that is valid until someone notices and rotates it.”
The arrival of agentic AI systems in production has made visible a problem that was already present at smaller scale. An agent is a machine. It authenticates to tools, APIs, databases, other agents, model providers, and payment systems. The pattern the industry defaults to is the pattern it has always defaulted to: issue the agent an API key and put it in an environment variable. The problem is familiar because it has been creating problems for service authentication for fifteen years.
On one engagement we completed earlier this year, the question of how an orchestrating agent would authenticate to its tools surfaced midway through the design phase, when the first tool list had been assembled and someone asked how credentials would be managed across tasks the agent might pause and resume over several hours. The default answer, the environment variable rotated on deployment, was the answer because it was the available answer, not because it was the right one. The right answer required the team to encounter SPIFFE for the first time. It had existed for years.
#06The counter-argument
The case against SPIFFE and SPIRE adoption at general scale is straightforward. SPIRE adds operational complexity: a node agent on every host, a server managing trust bundles, an attestation model configured for the deployment environment. For a team running two services that call each other, the overhead is disproportionate to the problem it solves. An API key rotated regularly is the correct tool for that deployment size. The argument for SPIFFE is not that shared secrets should be abolished everywhere; it is that shared secrets should not remain the default for systems whose scale and risk profile have already passed the point where the weaknesses are consequential.
The tooling is also not as mature as the trade's tooling for human authentication. The OAuth SPIFFE client authentication draft is at version 02 as of June 2026 and is not yet a standard. The integration between SPIFFE-issued identities and the OAuth-based flows that most APIs use is narrower than it should be for general adoption. Hiring engineers familiar with SPIRE is harder than hiring engineers familiar with OAuth. The reputational shadow cast by certificate authority failures and revocation infrastructure that did not function as specified falls on cryptographic identity concepts as well as on the specific implementations that failed. None of this makes the decision to default to a static secret for a new agentic deployment sound. It means the better answer requires deliberate effort to reach, and that the effort should be expected rather than avoided.
The SPIFFE and SPIRE maintainers built the correct abstraction. The CNCF ecosystem deployed it. Kubernetes service accounts, which issue short-lived automatically-rotated tokens following the same principles, are in use in many organisations that have not yet applied the same pattern to the non-Kubernetes parts of their service estates. The agent wave has not created the machine identity problem. It has made the problem impossible to continue deferring. The engineering community that spent ten years solving how people authenticate already knows how to solve this. The question is whether teams building with agents in 2026 will look for the answer that already exists, or solve it again from the API key up.