Workload identity

The problem workload identity solves is the static secret. A long-lived API key is a string: anything holding it is the caller, it stays valid until somebody revokes it, and rotating it is a manual act, which means it is rare, which means credentials accumulate in configuration stores, CI variables and developer laptops. Workload identity removes the stored secret from the design. The platform attests what is running — this pod, in this namespace, from this image, in this account — an issuer signs an assertion of that fact, and the assertion is exchanged for a credential measured in minutes rather than months.

The forms differ but share a shape. SPIFFE and its reference implementation issue X.509 or JWT identity documents to attested workloads and rotate them automatically. Cloud platforms attach identities to instances and functions, retrievable from a metadata endpoint the workload cannot lie about. OIDC federation lets a CI system or a Kubernetes cluster act as an issuer whose tokens another party will trust. In each case there is no durable secret at rest, the identity document has a short lifetime, and rotation happens without anyone deciding to do it.

For agents the important move is composing that with the other two identities in play, because the workload is not the agent. One pod may run several agents, and one agent may move between pods within a deployment. A useful exchange therefore proves a composite fact rather than a single subject: which workload, which registered agent, which human actor, and which task — with the agent and the human bindings checked against records the receiving system owns rather than taken from the assertion. What it mints in return should be short-lived, bound to a specific audience, scoped to a specific operation, and consumable once, so that capturing it in a log buys an attacker a couple of minutes against one endpoint rather than a credential.

That composite is what lets a receiving system stop accepting assertions it cannot check. A request authenticated by a verified exchange carries provenance a header can only claim, so the correct response to a caller-supplied delegation chain on such a request is to refuse it outright rather than record it beside verified claims as though the two were the same kind of thing, and the named human should be bound to the identity the exchange actually verified. This is the one place where the weaker header-based controls can be turned off rather than merely supplemented.

The limits deserve equal billing. A short-lived capability is still a bearer credential for its lifetime, so the gain is a smaller window rather than a different class of protection, unless it is additionally bound to a key the holder must prove possession of. Attestation binds the credential to a workload at the moment of issue, not at the moment of use. Issuer, audience and key location all have to be pinned by an operator rather than discovered from the untrusted assertion, or a token gets to choose where its own verification keys are fetched from. Replay protection has to consume both the assertion and the minted capability in a store every replica shares, or two replicas are two replay domains.

And the honest constraint on adoption, which decides what most estates actually run: mainstream agent frameworks and SDKs authenticate by putting a string into a header. Presenting a client certificate or driving a token exchange requires custom transport configuration inside the customer’s agent, which is the difference between changing a base URL and running a project. So workload identity tends to arrive as an opt-in path alongside static keys rather than as a replacement for them, and until it is the only path, the permission model rather than the credential is what bounds an incident.